Update (July 11, 2023)
As already described in VonC's answer, the GitHub CLI now has a dedicated cache
top-level command:
List of caches for the current repository:
$ gh cache list
Delete a cache for the current repository by cache ID:
$ gh cache delete <CACHE_ID>
Update (October 20, 2022)
You can now manage caches via the UI:
https://github.com/<OWNER>/<REPO>/actions/caches
Update (June 27, 2022)
You can now manage caches via the GitHub Actions Cache API:
GET
list of caches for a repository:$ curl \ -H "Accept: application/vnd.github.v3+json" \ -H "Authorization: token <TOKEN>" \ https://api.github.com/repos/<OWNER>/<REPO>/actions/caches
DELETE
a cache for a repository by cache ID:$ curl \ -X DELETE \ -H "Accept: application/vnd.github.v3+json" \ -H "Authorization: token <TOKEN>" \ https://api.github.com/repos/<OWNER>/<REPO>/actions/caches/<CACHE_ID>
Alternatively, you can also use the GitHub CLI to interact with the API, using the gh-actions-cache extension.
Original Post (November 13, 2020)
As pointed out in the corresponding issue, two practical workarounds can be used to force the use of a new cache. This is not exactly the same as clearing the current cache (with regards to the cache usage limits), but it does the job.
In order to do so, you have to change the cache key
(and any restore-keys
). Because if the key(s) is/are different, this is considered a cache miss and you start with a new one.
You can change the cache key either by modifying the workflow file directly, e.g., by adding a version number:
key: ${{ runner.os }}-mycache-v1-${{ hashFiles(...) }}
If you now want to use a new cache, all you have to do is to commit a different version number:
key: ${{ runner.os }}-mycache-v2-${{ hashFiles(...) }}
If you don't want to modify the workflow file and prefer using the UI, you can abuse secrets:
key: ${{ runner.os }}-mycache-${{ secrets.CACHE_VERSION }}-${{ hashFiles(...) }}
Whenever the secret changes, a new cache will be used.
⚠️WARNING: Secrets used for cache keys are "revealed" in the UI.