Repository navigation
Add additional exit codes for gh cache delete --all #9897
Description
Describe the feature or problem you’d like to solve
I use gh cache delete --all to purge all cache related to a workflow that stores ephemeral items in cache.
- When cache items are present and they are successfully removed, the command returns an exit code of 0.
- When no cache items are present, the command returns an exit code of 1.
Unless I parse standard error to read the message for the first case, I can't disambiguate it between an invocation that did not find any cache to remove, and one that did but failed to successfully remove it.
Proposed solution
I propose a unique exit code for the specific case where no cache items were found. This would allow callers to treat this use case as a success and disambiguate it from any genuine errors.
This would simplify its usage for this use case significantly.
Additional context
According to the manual, it appears this would not fall outside of the cli's existing behavior.
Activity
williammartin commentedon Nov 11, 2024
For some background, typically, if you are specifying a resource directly, we treat it as a failure since silently failing to remove the resource you expected to can be quite frustrating. That's why
gh cache delete <cache-id>will error if the cache-id isn't found.However, in this case, what the user is trying to convey is "I want all caches gone" and we can indicate they are all gone with a
0exit code. The same error behaviour exists over oncodespace delete --allbut there's also no test for it so I'm not sure how much that behaviour was cared about.The question is, is there anyone out there who might be relying on the current behaviour. This is technically a breaking change, I'm just trying to figure out whether it would matter. It seems unlikely.
Also, I wonder if it's possible to disambiguate "there are no caches" and "this token doesn't have permission to see the caches". Both might return
404? If these were indistinguishable, returning0for--allcould be tricky.I'm going to put a
discusslabel on this for the team to chat.williammartin commentedon Nov 13, 2024
It looks like listing caches and deleting caches both only require
reposcope, and that's required forghto work so this doesn't appear to be an issue https://docs.github.com/en/rest/actions/cache?apiVersion=2022-11-28#list-github-actions-caches-for-a-repositorywilliammartin commentedon Nov 19, 2024
In the interest of not breaking backwards compatibility, I'm going to suggest the introduction of a new flag here
--succeed-on-no-caches. This should only be usable with--all. I'm not looking to introduce idempotent deletes on singular resources, since that will be a large new UX across the entire CLI.Acceptance Criteria
Given I have no caches
When I run
gh cache delete --all --succeed-on-no-cachesThen it exits
0When I run
gh cache delete <cache-id> --succeed-on-no-cachesThen I get an error that
--succeed-on-no-cachescan only be used in conjunction with--all