Checking out HEAD instead of latest published recipe version #620

New Issue

2024-06-25T13:40:48Z

decentral1se commented

2024-06-25 13:40:48 +00:00

Follow-up for coop-cloud/organising#617. Opening so we don't lose track. Report to follow but other commands are suffering from this issue... @simon interested in trying to fix this soo-ish 👍

Follow-up for https://git.coopcloud.tech/coop-cloud/organising/issues/617. Opening so we don't lose track. Report to follow but other commands are suffering from this issue... @simon interested in trying to fix this soo-ish 👍

decentral1se added the bug abra labels 2024-06-25 13:40:48 +00:00

~~decentral1se referenced this issue 2024-06-25 13:41:15 +00:00~~

`abra` v0.10.x-beta release planning #583

decentral1se commented

2024-06-29 16:44:25 +00:00

OK, yes, this is an issue. Working on #584, I've noticed that a few commands do still default to checking out HEAD instead of the latest published version. This might be some work to figure it out which commands are doing that and fix them up (adding --chaos where needed to keep the current functionality).

OK, yes, this is an issue. Working on #584, I've noticed that a few commands do still default to checking out `HEAD` instead of the latest published version. This might be some work to figure it out which commands are doing that and fix them up (adding `--chaos` where needed to keep the current functionality).

decentral1se changed title from ~~#617 follow-ups~~ to Checking out HEAD instead of latest published recipe version

2024-06-29 16:45:11 +00:00

decentral1se commented

2024-06-30 12:09:05 +00:00

Oof this is worse than I thought 😬 Take this for example:

abra app deploy abra-test-recipe.example.com 0.1.1+1.20.2
abra app undeploy abra-test-recipe.example.com
abra app secret rm abra-test-recipe.example.com --all

Then abra app secret command will check out HEAD and try to delete secrets in the current implementation 🙉 This can end up not finding secrets from previous versions or deleting new secrets unintentionally. The only way to work-around this atm is to pass --chaos to abra app secret rm ....

abra app secret doesn't take a <version> argument and I don't imagine that would be intuitive? I'm not sure on this. This example does seem to be the limit of how abra auto-magically selects which version to deal with.

Do we maybe need to start thinking in terms of users selecting the version themselves? This would be a one-time operation to switch "modes" perhaps 🤔 abra app mode <domain> [--chaos] [<version>] or something (abra app version ... already taken...). So you could abra app mode abra-test-recipe.example.com 0.1.1+1.20.2 in the above example and all commands would use that version seamlessly? The default could be locking to the latest release version.

This might actually dovetail quite nicely with fixing the version of the app in the .env file?

Oof this is worse than I thought 😬 Take this for example: ``` abra app deploy abra-test-recipe.example.com 0.1.1+1.20.2 abra app undeploy abra-test-recipe.example.com abra app secret rm abra-test-recipe.example.com --all ``` Then `abra app secret` command will check out `HEAD` and try to delete secrets in the current implementation 🙉 This can end up not finding secrets from previous versions or deleting new secrets unintentionally. The only way to work-around this atm is to pass `--chaos` to `abra app secret rm ...`. `abra app secret` doesn't take a `<version>` argument and I don't imagine that would be intuitive? I'm not sure on this. This example does seem to be the limit of how `abra` auto-magically selects which version to deal with. Do we maybe need to start thinking in terms of users selecting the version themselves? This would be a one-time operation to switch "modes" perhaps 🤔 `abra app mode <domain> [--chaos] [<version>] ` or something (`abra app version ...` already taken...). So you could `abra app mode abra-test-recipe.example.com 0.1.1+1.20.2` in the above example and all commands would use that version seamlessly? The default could be locking to the latest release version. This might actually dovetail quite nicely with fixing the version of the app in the `.env` file?

👀 1

moritz commented

2024-07-02 16:30:24 +00:00

Related: coop-cloud/organising#541
I think the best solution would be to fix the version of the app in the .env file.

as <version> is an optional argument I would prefer to provide it as flag, like --app-version= this would be less confusing, especially for commands like abra app secret

Related: https://git.coopcloud.tech/coop-cloud/organising/issues/541 I think the best solution would be to fix the version of the app in the .env file. as `<version>` is an optional argument I would prefer to provide it as flag, like `--app-version=` this would be less confusing, especially for commands like `abra app secret`

decentral1se commented

2024-07-03 07:07:36 +00:00

Oh shit right @moritz, I finally get that issue. Actually, I think it's a duplicate? Let's converge on coop-cloud/organising#541

Oh shit right @moritz, I finally get that issue. Actually, I think it's a duplicate? Let's converge on https://git.coopcloud.tech/coop-cloud/organising/issues/541

decentral1se closed this issue

2024-07-03 07:07:36 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#620