Add optional <version> argument to abra app secret rm to allow deleting a specific secret version #615

New Issue

2025-08-25T20:06:58Z

3wordchant commented

2025-08-25 20:06:58 +00:00

...because otherwise it tries to delete all versions and the only way to delete a single version is with docker secret rm

...because otherwise it tries to delete all versions and the only way to delete a single version is with `docker secret rm`

👍 2

3wordchant added the enhancement label 2025-08-25 20:06:58 +00:00

decentral1se added this to the Abra v0.11.x project 2025-08-29 14:45:18 +00:00

decentral1se moved this to In Progress in Abra v0.11.x on 2025-08-30 10:04:59 +00:00

decentral1se commented

2025-08-30 11:21:54 +00:00

@3wordchant digging into this and wanted to pick your brain on this one...

i guess it's a bug that we should really only be deleting the secret that matches the version we put in the .env for abra app secret rm invocations. You shouldn't have to put a [version] argument to not nuke your entire history of secrets v[n] back to 1? and actually this breaks rollbacks which might look for a specific version of a secret? 🙈 so, let's fix that as the new default of this sub-command?

i also noticed abra app secret ls doesn't show secrets that don't match what you put in your .env, e.g. if you have SECRET_FOO_VERSION=v2 then abra app secret ls <domain> will only match secret_foo_v2 when querying internally. that actually seems now limited in this use-case. should we be making a distinction in abra app secret ls on which secret version is used and which is present but unused for a specific app? The only way (AFAICT) to know there are other "old" secrets present is to use docker secret ls?

then you could know what you need to fill in for abra app secret rm [secret] [version] by running abra app secret ls first? probably we should prompt a warning "are you sure cus it could break rollback" when deleting a specific version (with --no-input flag available)?

@3wordchant digging into this and wanted to pick your brain on this one... i guess it's a bug that we should really only be deleting the secret that matches the version we put in the `.env` for `abra app secret rm` invocations. You shouldn't have to put a `[version]` argument to not nuke your entire history of secrets `v[n]` back to 1? and actually this breaks rollbacks which might look for a specific version of a secret? 🙈 so, let's fix that as the new default of this sub-command? i also noticed `abra app secret ls` doesn't show secrets that don't match what you put in your `.env`, e.g. if you have `SECRET_FOO_VERSION=v2` then `abra app secret ls <domain>` will only match `secret_foo_v2` when querying internally. that actually seems now limited in this use-case. should we be making a distinction in `abra app secret ls` on which secret version is used and which is present but unused for a specific app? The only way (AFAICT) to know there are other "old" secrets present is to use `docker secret ls`? then you could know what you need to fill in for `abra app secret rm [secret] [version]` by running `abra app secret ls` first? probably we should prompt a warning "are you sure cus it could break rollback" when deleting a specific version (with `--no-input` flag available)?

decentral1se self-assigned this 2025-08-30 11:22:17 +00:00

3wordchant commented

2025-09-02 18:29:54 +00:00

i guess it's a bug that we should really only be deleting the secret that matches the version we put in the .env for abra app secret rm invocations [...] so, let's fix that as the new default of this sub-command?

Agreed.

i also noticed abra app secret ls doesn't show secrets that don't match what you put in your .env

Sounds sensible, maybe a separate ticket for this? Seems lower priority than making abra app secret rm not delete unexpected things.

> i guess it's a bug that we should really only be deleting the secret that matches the version we put in the `.env` for `abra app` secret rm invocations [...] so, let's fix that as the new default of this sub-command? Agreed. > i also noticed abra app secret ls doesn't show secrets that don't match what you put in your `.env` Sounds sensible, maybe a separate ticket for this? Seems lower priority than making `abra app secret rm` not delete unexpected things.

👍 1

decentral1se referenced this issue from a commit

2025-09-03 07:39:41 +00:00

test: ensure previous versions not deleted

decentral1se referenced this issue

2025-09-03 07:40:07 +00:00

test: ensure previous secret versions not deleted #642

3wordchant commented

2025-09-03 15:19:29 +00:00

Ah @decentral1se I was wrong about "tries to delete all versions", it tries to delete the version specified in the .env.

So I think !642 looks good, and this remains a feature request to be able to delete a specific version :)

Ah @decentral1se I was wrong about "tries to delete all versions", it tries to delete the version specified in the `.env`. So I think !642 looks good, and this remains a feature request to be able to delete a specific version :)

👍 1

decentral1se commented

2025-09-04 08:26:07 +00:00

Nice, thanks! OK I'm gonna then bump this outta the current code crunch into the new version and we can come back to it. Some of these design questions are still hanging in the air (#615 (comment)) and it would be good to take some time to think about it.

Nice, thanks! OK I'm gonna then bump this outta the current code crunch into the new version and we can come back to it. Some of these design questions are still hanging in the air (https://git.coopcloud.tech/toolshed/abra/issues/615#issuecomment-26575) and it would be good to take some time to think about it.

👍 1

decentral1se removed this from the Abra v0.11.x project 2025-09-04 08:26:12 +00:00

decentral1se referenced this issue from a commit

2025-09-04 08:26:22 +00:00

test: ensure previous versions not deleted

Sign in to join this conversation.