Cache the gitleaks download so a GitHub outage can't fail the build - #662
Merged
Merged
Conversation
fogwall-core downloads the gitleaks binary into build/generated-resources at build time, and `gradle clean` — which every image build and fresh CI runner does — wipes it, so it re-downloads from GitHub's release CDN on every build. A transient 504 from that CDN recently failed the image build and the e2e job. downloadGitleaks now reuses a binary from an optional cache directory (GITLEAKS_CACHE_DIR) and writes a freshly downloaded one back to it, keyed by version so a bump never serves a stale binary. The directory is deliberately outside anything Gradle manages, so it can't disturb the build cache or the setup-gradle action; when the variable is unset — a laptop, a fresh clone — the task downloads exactly as before. The download also retries a few times, so a flaky fetch is a slow build rather than a red one. CI populates the cache: the Dockerfile mounts it as a BuildKit cache, and the gradle jobs restore it with actions/cache keyed on the gitleaks version. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
coopernetes
force-pushed
the
chore/gitleaks-download-cache
branch
from
September 14, 2026 16:38
59f5af8 to
051d609
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fogwall-coredownloads the gitleaks binary intobuild/generated-resourcesat build time and packs it into the jar.gradle clean— which every image build and every fresh CI runner does — wipes that, so the binary is re-downloaded from GitHub's release CDN on every build. Nothing caches it: the Docker cache mounts andsetup-gradlecover~/.gradle(deps), not the project build dir. A transient 504 from that CDN recently failed both the image build and the e2e job.What changed
downloadGitleaksgains an optional, CI-owned cache and a retry:GITLEAKS_CACHE_DIRpoints somewhere, a binary already there is reused and a freshly downloaded one is written back, keyed by version (gitleaks_<version>_<target>) so a bump never serves a stale binary.The cache dir is deliberately outside anything Gradle manages, so it can't disturb the build cache or the
setup-gradleaction's save/restore.CI populates it: the Dockerfile mounts
/gitleaks-cacheas a BuildKit cache and setsGITLEAKS_CACHE_DIRfor the image build; the four gradle-on-runner jobs (build, e2e, compose smoke, playwright) restore~/.cache/gitleakswithactions/cachekeyed on the gitleaks version.Testing
Ran
downloadGitleakslocally in all three modes: unset (downloads, leaves~/.gradleuntouched), cache set + empty (downloads and populates), cache set + populated (restores, no download).🤖 Generated with Claude Code