Global version specification for abra app ... <version>
#541
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 .envFor 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.decentral1se referenced this issue2024-07-03 07:08:36 +00:00
Plan coming together:
.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#533I'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 usingdeploy
/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...