An Android release pipeline consumed several times GitHub's 500MB Actions quota in about ten days

The line that did the damage is the cache key:

`key: ${{ runner.os }}-gradle-${{ hashFiles('android/gradle/wrapper/gradle-wrapper.properties', 'android/build.gradle') }}` ^[6]

Both paths live under an `android/` directory that is .gitignored and generated later, inside the build script's own prebuild step ^[7]. When the cache step runs, neither file is on disk yet. `hashFiles()` against paths that do not exist returns an empty string every time, so the key never varied with the real config ^[8].

That breaks the cache in both directions. Restores always miss, so every build re-downloaded every Gradle dependency ^[9]. Saves always write, and GitHub scopes Actions caches per branch by default, so a cache saved on one branch is not shared with another; it is a full new copy ^[10]. Ten active branches held ten copies of the same dependency set at once, and none of them aged out, because ongoing work on each branch kept refreshing its own ^[11]. The dev.to post describes the two bugs as one root: a cache system that looked like it was working, doing none of its actual job, on both counts ^[19].

The artifact side is simpler to add up. The allowance is 500MB, total, org-wide ^[2]. A signed release AAB is about 70MB ^[4]. Seven of them is 490MB, or 98 percent of what the free plan gives the entire organisation, and those files carried 30-day retention because that is the number Actions suggests and nobody changed it ^[1][13]. Artifacts had reached nearly two gigabytes in about two weeks, four times the quota without counting a single cache ^[3][2].

The error message points at artifacts. They were the smaller half of the problem. According to the write-up, ten duplicate caches never appear in any failure output, and finding them meant going past the summary usage figures to list every artifact and every cache for the repository through `gh api` with `--paginate` ^[16][15].

This reaches your pipeline only on a free org plan, with build outputs measured in tens of megabytes, retention left at the default, and enough concurrent branches to multiply the cache ^[2][10][13]. The rate you approach the 500MB is artifact size times retention days, plus branch count times cache size. A repo whose artifacts are a few megabytes takes far longer to reach the same wall, and the per-branch duplication is waiting there when it does.

Cleanup helped, per the post, though the real fix lies elsewhere; the conclusion the author draws is that this pipeline should never again depend on GitHub's shared minutes or storage at all ^[17]. Part 4 covers that redesign and the first real production ship ^[18].