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

Allow usage of environments #38

Closed
adamkiss opened this issue Jan 30, 2023 · 6 comments · Fixed by #78
Closed

Allow usage of environments #38

adamkiss opened this issue Jan 30, 2023 · 6 comments · Fixed by #78

Comments

@adamkiss
Copy link
Contributor

adamkiss commented Jan 30, 2023

For many tasks a user might want to do with a cli command, configuration differs for production/staging/dev environments.

Kirby solves this very elegantly with config.domain.ext.php files, but these are not available in the cli commands (Logically, even though that was not a fun debugging session).

I'd like then, to somehow pass the environment - probably the domain to use, so we could use the existing configuration - to cli.

There are two options:

1.) Use a command argument

kirby custom:command -e production.com -a 'argument for command'

2.) Use an environment value

env env=production.com kirby custom:command -a 'argument for command'

I personally prefer the option 1 (argument), but that would be a first kind of argument not passed through to command, so I'm not sure if that's a good idea or not.

@lukasbestle
Copy link
Member

I guess if we make it an argument, it could come before the command to distinguish it from a command argument:

kirby -e production.com custom:command -a 'argument for command'

Regarding the two options: Why not both? We could even set the env variable up in a way that it can be used in a shell profile (e.g. .zshrc or .bash_profile), i.e. the name should be specific to Kirby (like KIRBY_ENV).

@adamkiss
Copy link
Contributor Author

@lukasbestle I… have no opinion. My use cases are mostly stuff like live services vs. mock services (email sending, third party API, etc), where you defensively set the mock as default and override in production, so setting env in the shell profile is… 🤷🏻‍♂️

re: order: I think that's too complicated I think long --env argument is much more readable. Also, I don't know if the underlying CLI parser is capable of distinguishing stuff like "argument before the command".

If I can do anything (sketch PR with env maybe?) to have this released faster, let me know

@bogdancondorachi
Copy link

bogdancondorachi commented Feb 1, 2023

I get the following errors when trying to enter kirby commands in my website directory, is this related to this issue?

I'm running different environment configurations, also testing with starterkit is seems to work as expected

Kirby\Exception\InvalidArgumentException: The environment is not allowed in /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:245
Stack trace:
#0 /var/www/html/vendor/getkirby/cms/src/Http/Environment.php(177): Kirby\Http\Environment->detectAllowed()
#1 /var/www/html/vendor/getkirby/cms/src/Http/Environment.php(108): Kirby\Http\Environment->detect()
#2 /var/www/html/vendor/getkirby/cms/src/Cms/App.php(1095): Kirby\Http\Environment->__construct()
#3 /var/www/html/vendor/getkirby/cms/src/Cms/App.php(104): Kirby\Cms\App->optionsFromEnvironment()
#4 /var/www/html/public/index.php(7): Kirby\Cms\App->__construct()
#5 /home/alex/.config/composer/vendor/getkirby/cli/bootstrap.php(16): require('...')
#6 /home/alex/.config/composer/vendor/getkirby/cli/bin/kirby(9): Kirby\CLI\bootstrap()
#7 /home/alex/.config/composer/vendor/bin/kirby(120): include('...')
#8 {main}
Kirby\Exception\InvalidArgumentException: The environment is not allowed in file /var/www/html/vendor/getkirby/cms/src/Http/Environment.php on line 245
Stack trace:
  1. Kirby\Exception\InvalidArgumentException->() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:245
  2. Kirby\Http\Environment->detectAllowed() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:177
  3. Kirby\Http\Environment->detect() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:108
  4. Kirby\Http\Environment->__construct() /var/www/html/vendor/getkirby/cms/src/Cms/App.php:1095
  5. Kirby\Cms\App->optionsFromEnvironment() /var/www/html/vendor/getkirby/cms/src/Cms/App.php:104
  6. Kirby\Cms\App->__construct() /var/www/html/public/index.php:7
  7. require() /home/alex/.config/composer/vendor/getkirby/cli/bootstrap.php:16
  8. Kirby\CLI\bootstrap() /home/alex/.config/composer/vendor/getkirby/cli/bin/kirby:9
  9. include() /home/alex/.config/composer/vendor/bin/kirby:120

@lukasbestle
Copy link
Member

@bogdancondorachi What is your url option set to?

@adamkiss I agree, env would probably the easiest and most flexible. I'd still call it KIRBY_ENV though to avoid clashes with other tools.

@bezin
Copy link

bezin commented May 3, 2024

Hi all,

I ran into the same issue, while developing our email check plugin. Is there any news on this? I personally would prefer a --host or --env argument to every command, but the order of arguments must not matter – that is just confusing IMO.

I wouldn't mind an argument and the environment variable being implemented, though 😉

@bastianallgeier bastianallgeier linked a pull request May 3, 2024 that will close this issue
@bastianallgeier
Copy link
Member

It's coming to 1.5.0 with the new KIRBY_HOST env variable.

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.

5 participants