Skip to content
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

Open
sestrella opened this issue Aug 8, 2017 · 10 comments
Open

Single configuration file #76

sestrella opened this issue Aug 8, 2017 · 10 comments

Comments

@sestrella
Copy link
Member

Most of the settings across different deployment scripts such as staging.yaml and production.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:

repo: [email protected]:<org>/<repo>
build_script:
   - stack setup
   - stack build
restart_command: <restart command>

staging:
  revision: origin/master

production:
  revision: origin/production

Then we could change the CLI to take a section as an argument:

$ stack exec hap -- deploy staging
$ stack exec hap -- deploy production
``
@juanpaucar
Copy link
Contributor

juanpaucar commented Sep 5, 2017

@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. development -> staging -> qa -> production. In those scenarios we would still need another yaml file

@ibarrae
Copy link
Contributor

ibarrae commented Aug 11, 2022

Maybe this could be achieved using TOML files @sestrella? https://kowainik.github.io/posts/2019-01-14-tomland#prefix-tree

@sestrella
Copy link
Member Author

@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?

@CristhianMotoche
Copy link
Collaborator

@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.

@DavidMazarro
Copy link
Member

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.

@CristhianMotoche
Copy link
Collaborator

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 version is not given it will take the current version (let's call it 1). Would that make sense?

@CristhianMotoche CristhianMotoche added the under review Review the relevance of the issue/pull request label Mar 20, 2023
@sestrella
Copy link
Member Author

@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

@CristhianMotoche
Copy link
Collaborator

CristhianMotoche commented Apr 3, 2023

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.

@CristhianMotoche CristhianMotoche added feature-request and removed question under review Review the relevance of the issue/pull request labels Apr 3, 2023
@CristhianMotoche
Copy link
Collaborator

Hey team! I'm assigning @well1791 to this issue since he wants to give it a try. Let me know @well1791 if there is anything that you need from my end.

@CristhianMotoche
Copy link
Collaborator

Hello @well1791 I was wondering if everything is clear with this issue. Do you need any help to review it? Let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants