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:
-
GETlist 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 -
DELETEcache for a repository using a 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.