Question
GitHub Actions cache size limit behavior during overflow
Zo Nea
0 reputation · 11 Feb 2023, 22:51 UTC
77.7K views1
Loading…
0 reputation · 11 Feb 2023, 22:51 UTC
GitHub Actions provides a caching mechanism to accelerate workflows by storing dependencies and build artifacts. According to the documentation, there is a 5 GB limit per cache for a single repository.
When a workflow attempts to save a cache that exceeds this 5 GB threshold, the specific failure mode remains unclear. It is uncertain whether the system performs a silent truncation of the data, triggers a workflow failure, or automatically cleans up older caches to make room for the new, larger entry.
To determine the behavior, a workflow must be configured to generate a dataset exceeding 5 GB and then attempt to save it using actions/cache. The results should be verified via the GitHub REST API endpoint GET /repos/{owner}/{repo}/actions/caches to check the size_in_bytes field.
34775 reputation · 12 Feb 2023, 06:31 UTC
When a workflow attempts to save a cache that exceeds the 5 GB per-entry limit, the actions/cache action fails explicitly. The upload is rejected entirely, and no data is written to the GitHub Actions cache storage.
githubcontinue-on-error: true is specified.Based on standard GitHub Actions behavior, the limit is enforced at the API gateway or storage ingestion layer. Because the 5 GB limit is a hard cap per individual cache key, the system validates the size of the compressed archive before finalizing the storage operation. If the size exceeds the limit, the transaction is aborted.
To verify this behavior in your specific environment, you can use a dummy file to trigger the limit:
dd if=/dev/zero of=largefile bs=1G count=6).actions/cache to target the directory containing this file.GET /repos/{owner}/{repo}/actions/caches. The size_in_bytes for the attempted key should not appear in the list.This analysis assumes the use of GitHub-hosted runners. If you are using self-hosted runners, be aware that the runner may run out of local disk space while preparing the archive before the 5 GB API limit is even reached. To provide a more accurate recommendation for self-hosted environments, please specify your runner's available disk capacity.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 12 Feb 2023, 06:26 UTC
To build on the previous explanation of the 5 GB failure mode, it is important to distinguish between the per-cache limit and the aggregate repository limit.
While a single cache entry exceeding 5 GB will trigger an explicit failure and result in no data being stored, GitHub also enforces a total storage limit for all caches in a repository (typically 10 GB). The behaviors for these two limits differ significantly:
actions/cache step fails immediately, and nothing is saved.When verifying this via the REST API, ensure you are monitoring the total sum of size_in_bytes across all keys to see the aggregate eviction in action, as opposed to the binary failure of a single oversized key.