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

Set default deploy config on kamal init. #1424

Open
ShPakvel opened this issue Feb 22, 2025 · 1 comment · May be fixed by #1427
Open

Set default deploy config on kamal init. #1424

ShPakvel opened this issue Feb 22, 2025 · 1 comment · May be fixed by #1427

Comments

@ShPakvel
Copy link
Contributor

ShPakvel commented Feb 22, 2025

Context

Right now all kamal deployment related files stored in .kamal dir, except main deploy.yml config, which is stored in config/deploy.yml by default.

Some of us want to have all files related to kamal deployment in one dir .kamal.
Others also can have different locations for some reason.

We can specify config file via --config-file=CONFIG_FILE option on each kamal command invocation.
But it feels redundant and exhausting over time, especially with mostly manually invoking aliases-commands.

Taking into account that in most cases there will be one main deploy config, it would be nice to have this options saved on kamal init run and used automatically on other kamal commands.

Feature proposal

Feels like it can be achieved with minimal changes.

For example. There could be generated .kamal/options.yml or .kamal/defaults.yml file to save general/default options to use with all kamal future invocations.
We can read this config_file option from mentioned file and apply in the only place it is used (in file lib/kamal/cli/base.rb):

          commander.configure \
            config_file: Pathname.new(File.expand_path(options[:config_file])),

Note: .kamal/options.yml should be suitable solution to eliminate issues and ours of recovery when forgetting to specify options. E.g. setting default destination as staging for safety.

@djmb Let me know your thoughts on this extension proposal. I can take care of implementation if it sounds interesting.

@ShPakvel ShPakvel linked a pull request Feb 23, 2025 that will close this issue
@ShPakvel
Copy link
Contributor Author

I decided to address it right away, as it is localized change and useful. I created PR linked to this issue. Covered with couple new tests.

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

Successfully merging a pull request may close this issue.

1 participant