Repository navigation
fix(ci): isolate the yum cache mount per concurrent bottlecap build - #1483
lucaspimentel wants to merge 2 commits into
Conversation
❌ ErrorsYour PR has failed checks. Please review the issues below and take necessary action before merging. 🚦 2 Pipeline jobs failed
Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: cb3bc0b | Docs | View more details | Give us feedback! |
fb8debd to
498f790
Compare
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
🟢 Approval recommended
The change isolating the yum cache for concurrent builds has no active review issues.
No open issues 🎉
What changed in this PR
This PR isolates the yum cache used by concurrent Bottlecap compile builds to address intermittent dependency-install failures attributed to shared-cache races.
Changes:
- Adds
sharing=privateto the/var/cache/yumBuildKit cache mount, following the approach used for the cargo target cache in #1369. - Documents the isolation rationale; Alpine builds and cargo caches remain unchanged.
| File | Description |
|---|---|
images/Dockerfile.bottlecap.compile |
Makes the yum cache private to concurrent builds and adds explanatory comments. |
Review effort: Balanced
d3b58b0 to
e6cc6bf
Compare
Concurrent bottlecap compile jobs share one BuildKit yum cache mount, and some fail early at yum install with Errno 16 / HTTPS 416. Give each build its own yum cache with sharing=private, the same approach as the build-directory cache in #1369.
e6cc6bf to
cb3bc0b
Compare
Problem
bottlecap (*)compile jobs fail intermittently in the Docker build atyum install. The failure is always early (median 57 s into the job) and always recovers on the job's built-in retry, but each occurrence forces a full recompile of that flavor.Cause
The BuildKit cache mount for
/var/cache/yuminimages/Dockerfile.bottlecap.compilehas nosharingmode, so every concurrently-scheduledbottlecap (*)flavor that uses this Dockerfile shares one cache mount. All of them mutate it at once, so a build can read a repodata file or a cached.rpmthat another build is rewriting or pruning.This PR
Adds
sharing=privateto that one mount, so each concurrent build gets its own yum cache. Same approach and same syntax as #1369, which did this for the cargotargetmount in this file.Not changed: the alpine Dockerfile (it uses apk, not yum) and the cargo git/registry mounts, which #1369 deliberately left shared.
Tradeoff: private mounts mean no yum cache reuse across concurrent builds, so each concurrent build re-downloads its packages. Ephemeral runners start with empty caches anyway; unmeasured.
Testing
Test 1: the failure is current, and its signature matches a shared-cache race
Steps
bottlecap (*)compile job created between 2026-10-14 and 2026-11-05 inDataDog/datadog-lambda-extension, all refs (GET /projects/:id/jobs?scope[]=failed, paginated). 137 of them failed withscript_failure.Result
71 of the 137 (52%) failed in the
yum installstep with a symptom of the cache being mutated underneath the build:Metadata file does not match checksum, then[Errno 256] No more mirrors to tryonrepodata/primary.sqlite.gz[Errno 16] error setting timestamp on fileon/var/cache/yum/.../*.rpmError: Cannot open file /var/cache/yum/.../*.rpm: [Errno 2] No such file or directoryduringInstalling :[Errno 14] HTTPS Error 416 - Requested Range Not Satisfiableon a.rpmURLThe subsets overlap; each of the 71 matches at least one.
This is not a stale sample. The failures recur at a steady rate through 2026-11-04: 6 on 10-28, 2 on 10-29, 4 on 10-30, 5 on 11-02, 6 on 11-03, 6 on 11-04, then none on the partial day of 11-05.
They also cluster by minute, which is what a shared mount predicts: on 2026-10-19, 8 failed within 09:18-09:20 across different pipelines.
Cost: of the 67 (pipeline, job) pairs involved, 66 passed on a retry (62 on the first, 4 on the second). Failed attempts run 33 to 98 s, median 57 s, so the cost is the retry and the recompile it triggers, not a blocked pipeline.
Test 2: the Dockerfile still parses
Steps
docker build --check -f images/Dockerfile.bottlecap.compile images/Result
Check complete, no warnings found.Limits
main). That is expected: the same Dockerfile builds on every ref, and the builds it competes with come from the whole project, not from one branch.script_failurecompile attempts with these literals disappear.