Automating Android Play Store Releases: Storage Quota
Part 3 of the Android release pipeline series explores hitting the 500MB free storage quota wall on GitHub Actions and discovering hidden costs.
Stock photo for illustration only, not from the actual event
- Part 3 of the multi-app Android release pipeline automation series tackles storage costs.
- GitHub Actions free tier provides a hard org-wide storage quota of 500MB.
- The root causes included branch-scoped Gradle caches and a broken cache key.
- The ultimate solution requires migrating the pipeline to a self-hosted runner.
This is part 3 of a 5-part series on automating a multi-app Android release pipeline. While parts 1 and 2 covered getting the pipeline operational with code signing, versioning, and tracks, this installment reveals what happened when a finished pipeline encountered a slow-burning cost problem nobody budgeted for.
Weeks after the pipeline stabilized, releases started failing with errors unrelated to code. GitHub's free-tier Actions storage quota is strictly capped at 500MB total, organization-wide, forever. Our pipeline quietly consumed several times that limit within approximately ten days.
The diagnosis revealed ten duplicate copies of the same Gradle cache due to default branch-scoping, a silently broken cache key, and a 30-day retention policy on release artifacts nobody was actually accessing. While cleanup helped temporarily, it was not the real fix.
Stock photo for illustration only, not from the actual event
Digging into why ten identical caches existed uncovered a compounding bug in the cache key implementation. Furthermore, the signed release AAB files sized around 70MB carried a 30-day retention window by default, serving purely as an unused debugging convenience since the builds were already published directly to the Play Store.
"Error: Failed to CreateArtifact: Artifact storage quota has been hit."
GitHub Actions Error Message
Resource quotas on hosted CI/CD platforms are classic silent bottlenecks for growing development teams. Org-wide shared limits on free tiers can quickly catch projects off guard as branching scales up. Transitioning to self-hosted infrastructure eliminates external rationing constraints, though it shifts environment maintenance and tool dependencies back onto the engineering team.
The definitive fix was abandoning dependence on shared hosted allowances entirely by moving the build job to a self-hosted runner under our own control. Although this migration introduced initial hurdles, such as missing diagnostic utilities like /usr/bin/time on the runner image, it firmly established full ownership of the pipeline's underlying infrastructure.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment