Global version specification for abra app ... <version> #541

Closed
opened 2023-11-30 15:56:36 +00:00 by moritz · 2 comments
Member

For some commands like abra app deploy/upgrade/rollback it's now possible to specify a version. But this introduces some inconsistencies as other commands will automatically check out the newest version like #519. Further there is the proposal to specify the version inside the .env file: coop-cloud/organising#533 (comment)
I would propose that (almost?) every abra app uses this version (either specified directly inside the command or via the env) to checkout the correct version. The version specified in the command should always be preferred over the version specified in the .env
For these commands I think it's critical:

  • abra app check
  • abra app command
  • abra app deploy
  • abra app upgrade
  • abra app rollback
  • abra app new
  • abra app secrets

Not sure if I forgot some, but I think if we use the version checkout globally for each abra app command we should do fine.

For some commands like `abra app deploy/upgrade/rollback` it's now possible to specify a version. But this introduces some inconsistencies as other commands will automatically check out the newest version like #519. Further there is the proposal to specify the version inside the .env file: https://git.coopcloud.tech/coop-cloud/organising/issues/533#issuecomment-19038 I would propose that (almost?) every `abra app` uses this version (either specified directly inside the command or via the env) to checkout the correct version. The version specified in the command should always be preferred over the version specified in the .env For these commands I think it's critical: - [ ] `abra app check` - [ ] `abra app command` - [x] `abra app deploy` - [x] `abra app upgrade` - [x] `abra app rollback` - [x] `abra app new` - [ ] `abra app secrets` Not sure if I forgot some, but I think if we use the version checkout globally for each `abra app` command we should do fine.
moritz added the
enhancement
label 2023-11-30 15:56:36 +00:00
decentral1se added the
abra
label 2024-03-27 06:21:33 +00:00
decentral1se added this to the (deleted) project 2024-07-03 08:07:04 +00:00
Owner

Plan coming together:

  • Merge coop-cloud/abra#432 (being able specify your own recipe repositories and versions in the .env, e.g. wordpress:1.3.2 and now including logic to write this to the .env when doing deploy ops). Closes coop-cloud/organising#533
  • Ensure "write version" is handled by all commands that should do that (deploy ops, e.g. "abra app upgrade"). Ensure "read version" is handled by all commands that should do that ("other ops", e.g. "abra app secret generate") as described above also.
  • Then we can move on to coop-cloud/organising#467 which will allow us to sync these versions. The config file change can help here too: coop-cloud/abra#419.
Plan coming together: * Merge https://git.coopcloud.tech/coop-cloud/abra/pulls/432 (being able specify your own recipe repositories and versions in the `.env`, e.g. `wordpress:1.3.2` and now including logic to write this to the `.env` when doing deploy ops). Closes https://git.coopcloud.tech/coop-cloud/organising/issues/533 * Ensure "write version" is handled by all commands that should do that (deploy ops, e.g. "abra app upgrade"). Ensure "read version" is handled by all commands that should do that ("other ops", e.g. "abra app secret generate") as described above also. * Then we can move on to https://git.coopcloud.tech/coop-cloud/organising/issues/467 which will allow us to sync these versions. The config file change can help here too: https://git.coopcloud.tech/coop-cloud/abra/pulls/419.
Owner

I've made sure the commands listed in this ticket are now getting tested for respecting this version value in the .env file: 8084bff104 There are surely more edge cases and things to fix up, I hope people can help with testing along. Not every command supports overriding with a [<version>] and this might be something to discuss design-wise. Right now, the only way to override is using deploy/upgrade/rollback. As far as I can tell from my local manual testing, this goes a long way towards making things more stable for individual operators...

I've made sure the commands listed in this ticket are now getting tested for respecting this version value in the `.env` file: https://git.coopcloud.tech/coop-cloud/abra/commit/8084bff1042f5d3a8d95589b9adfaf67e77f1c8b There are surely more edge cases and things to fix up, I hope people can help with testing along. Not every command supports overriding with a `[<version>]` and this might be something to discuss design-wise. Right now, the only way to override is using `deploy`/`upgrade`/`rollback`. As far as I can tell from my local manual testing, this goes a long way towards making things more stable for individual operators...
Sign in to join this conversation.
No description provided.