-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single configuration file #76
Comments
@sestrella Although, I'm totally aware that staging ideally should be a carbon copy of the production environment. I also think that sometimes we need flexibility and that a user may not be able to have the ideal scenario. In that sense, how would you suggest that we should handle the case when there is a difference between the necessary scripts between both. Also, it may exist the case when a project has more than one environment in continuos integration & delivery pipeline, g.e. |
Maybe this could be achieved using TOML files @sestrella? https://kowainik.github.io/posts/2019-01-14-tomland#prefix-tree |
@ibarrae sorry for the late response. I would suggest start taking a look at Dhall, perhaps? It looks promising and has Haskell support. @CristhianMotoche, @DavidMazarro any thoughts? |
@sestrella @ibarrae Why do you want to include a new notation for the build script? Is it impossible to accomplish this only with YAML? Please, let me know your thoughts. |
I haven't used Dhall but have known it for a while. Despite looking interesting, I think the sort of config users are doing with Hapistrano isn't complex enough to justify defaulting to Dhall (unless we want to support both languages for deployment scripts?). It might just make Hapistrano a bit harder to use for people unfamiliar with Dhall. I would try to review if this can be done in YAML directly like @CristhianMotoche says, but I don't recall it can be done off the top of my head. In that case, TOML is a good pick IMO: it looks like it supports that feature, and is as simple/easy to use as YAML. |
Hey @sestrella I think we could accomplish this defining a new file version. Like some tools (e.g. CircleCI, GH Actions) do it. I think something like: ---
version: 2
repo: [email protected]:<org>/<repo>
build_script:
- stack setup
- stack build
restart_command: <restart command>
targets:
- staging:
revision: origin/master
- production:
revision: origin/production If |
@CristhianMotoche yes, I think versioning the configuration file is required here to ensure backward compatibility. Additionally, maybe we could add a command to scaffold configuration files? I think that would make it easier for current users to familiarize themselves with the new schema: > hap init -v1 # outputs an example configuration file using the current schema
> hap init -v2 # outputs an example configuration file with the proposed schema |
I like that idea @sestrella Thanks for the suggestion! I propose to solve the new version of this issue first and then create a follow up issue with the command that you suggest. |
Hello @well1791 I was wondering if everything is clear with this issue. Do you need any help to review it? Let me know. |
Most of the settings across different deployment scripts such as
staging.yaml
andproduction.yaml
are the same. Usually, they only differ in the name of the branch, therefore I would like to propose to use a single configuration file with different sections instead of separate files, the format might look like:Then we could change the CLI to take a section as an argument:
The text was updated successfully, but these errors were encountered: