Repository navigation
fix(ci): add a second retry for docker-build - #2007
Conversation
The Build bot/backend/frontend/nginx failure isn't a one-off blip: BuildKit intermittently fails to resolve a COPY --from=stage reference (failed to calculate checksum of ref ...: not found), and which specific path it hits varies run to run - node_modules, dist, prisma, generated all reproduced. Disk pressure, GHA cache staleness, buildx version, and Dockerfile stage structure were all ruled out with direct evidence across #2003/#2004/#2005/#2006; this reads as upstream BuildKit/runner flakiness with a high enough per-attempt failure rate that a single retry isn't reliably enough headroom. Add a second retry (three attempts total) as a pragmatic mitigation while the root cause remains open upstream.
|
Warning Review limit reached
Next review available in: 32 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Failed to generate code suggestions for PR |
There was a problem hiding this comment.
All reported issues were addressed across 1 file
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
There was a problem hiding this comment.
Graphify reviewed this change.
Looks safe to merge — no coupling regressions and no blocking issues, checked against the code graph (not a self-assessment).
Graphify review — findings
This PR modifies the Docker build retry logic in the CI workflow. It changes the previous single retry step into a two-retry sequence (three total attempts), adding a new intermediate retry step (build-retry-1) with continue-on-error: true and updating the final retry's condition to trigger only when both the initial build and the first retry fail. An expanded comment explains the motivation as intermittent BuildKit COPY --from checksum failures. The surface area is limited to the ci.yml build job steps for the matrixed service builds.
No blocking issues surfaced.
Analysis details — impact, health, verification
Impact & health
Graphify review
Impact — 0 functions depend on the 0 functions this change touches.
Health — grade A; no new coupling hotspots.
Verification — 0 functions in the blast radius were not formally verified this run (proofs are advisory here).
Gate & verification
graphify gate
PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.
|
## Summary - Skip the gha layer cache import on docker-build retry attempts. ## Why #2006's own CI run gave the missing piece: all three attempts (build, retry 1, retry 2) failed identically within the same job, each time on the exact same buildx ref hash across multiple unrelated COPY paths (packages/shared/src/generated, packages/shared/dist, packages/bot/dist, prisma). cache-from is scoped identically (type=gha,scope=<service>) across every attempt in a job, so a retry that reimports a stale or corrupted gha cache entry fails identically instead of getting a fresh build. That's why the retry-count fix in #2007 did not save #2006's run. Adds a `use-cache` input to `docker-build-service` (default true) and sets it to false on both retry steps in ci.yml, so retries skip cache-from and build from scratch. cache-to stays on so a successful retry still writes a fresh cache for the next run. ## Test plan - [ ] CI docker-build matrix passes on this PR - [ ] Resync PR 2006 onto main once this merges and confirm its Build - bot / Build - backend go green <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Skip importing the GHA layer cache on docker-build retries to prevent repeated BuildKit failures. Retries now build fresh while still writing a new cache on success. - **Bug Fixes** - Added `use-cache` input to `./.github/actions/docker-build-service` (default `true`); set to `false` on retry steps in `ci.yml` to omit `cache-from`. - Keeps `cache-to: type=gha,mode=max` so successful retries repopulate the cache and resolves the "failed to calculate checksum of ref ...: not found" errors from stale `type=gha,scope=<service>` entries. <sup>Written for commit aee532a. Summary will update on new commits.</sup> <a href="https://cubic.dev/pr/LucasSantana-Dev/Lucky/pull/2008?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->
🤖 I have created a release *beep* *boop* --- <details><summary>2.39.3</summary> ## [2.39.3](v2.39.2...v2.39.3) (2026-08-12) ### Bug Fixes * **bot:** expose degraded-extractor signal and honest play error ([#1999](#1999)) ([8348bd6](8348bd6)) * **bot:** unlink dead Last.fm sessions on error 9 and notify once ([#1946](#1946)) ([d22b8bd](d22b8bd)) * **ci:** add a second retry for docker-build ([#2007](#2007)) ([9347c55](9347c55)) * **ci:** extract node_modules before per-workspace build steps run ([#2006](#2006)) ([ae577d1](ae577d1)) * **ci:** free disk space before Docker builds to prevent BuildKit GC race ([#2003](#2003)) ([5bcd388](5bcd388)) * **ci:** isolate docker cache scope by branch ([#2012](#2012)) ([5d25ec8](5d25ec8)) * **ci:** pin node:24-alpine base image by digest ([#2004](#2004)) ([f154bfe](f154bfe)) * **ci:** skip gha cache-from on docker-build retries ([#2008](#2008)) ([89dbb90](89dbb90)) * **ci:** split deps-production per production target ([#2005](#2005)) ([43aacce](43aacce)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).



Summary
Why
The failure isn't a one-off blip: BuildKit intermittently fails to resolve a COPY --from=stage reference (failed to calculate checksum of ref ...: not found), and which specific path it hits varies run to run (node_modules, dist, prisma, generated all reproduced across #2005/#2006). Disk pressure, GHA cache staleness, buildx version, and Dockerfile stage structure were all ruled out with direct evidence. This reads as upstream BuildKit/runner flakiness with a high enough per-attempt failure rate that a single retry isn't reliably enough headroom.
Test plan
Summary by cubic
Add a second retry to the docker-build matrix job (three attempts total) for
bot,backend,frontend, andnginxto mitigate intermittent BuildKit COPY-from failures and stabilize CI.Written for commit 9e0caf0. Summary will update on new commits.