Add optional <version> argument to abra app secret rm to allow deleting a specific secret version
#615
No Assignees
decentral1se
decentral1se
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#615
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?
...because otherwise it tries to delete all versions and the only way to delete a single version is with
docker secret rm@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
.envforabra app secret rminvocations. You shouldn't have to put a[version]argument to not nuke your entire history of secretsv[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 lsdoesn't show secrets that don't match what you put in your.env, e.g. if you haveSECRET_FOO_VERSION=v2thenabra app secret ls <domain>will only matchsecret_foo_v2when querying internally. that actually seems now limited in this use-case. should we be making a distinction inabra app secret lson 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 usedocker secret ls?then you could know what you need to fill in for
abra app secret rm [secret] [version]by runningabra app secret lsfirst? probably we should prompt a warning "are you sure cus it could break rollback" when deleting a specific version (with--no-inputflag available)?Agreed.
Sounds sensible, maybe a separate ticket for this? Seems lower priority than making
abra app secret rmnot delete unexpected things.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 :)
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.