fix(ci): expose ACTIONS_* runtime env so the e2e gha build cache engages - #1959
Conversation
The e2e build job builds via docker compose in a plain run step, which never sees ACTIONS_RUNTIME_TOKEN/ACTIONS_CACHE_URL — buildx silently drops the type=gha cache_from/cache_to wired in docker-compose.cache.yml, so every PR run fully recompiled analytics + identity-resolution + jira-enrich (~13.5 min) even with an unchanged Cargo.lock. crazy-max/ghaction-github-runtime exports those env vars to run steps, letting the existing cache overlay actually restore the dep layers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Anton Zelenov <antonz@constructor.tech>
📝 WalkthroughWalkthroughThe E2E workflow now exposes GitHub Actions runtime cache variables before ChangesE2E build cache runtime
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/e2e-bronze-to-api.yml (1)
88-94: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winRefresh and pin the runtime action revision.
The integration point is correct, but upstream currently documents
crazy-max/ghaction-github-runtime@v4; this workflow still uses@v3. Update to the supported revision and preferably pin its commit SHA to prevent unreviewed action changes. (github.com)Proposed change
- - uses: crazy-max/ghaction-github-runtime@v3 + - uses: crazy-max/ghaction-github-runtime@v4 # preferably pin to a verified commit SHA🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/e2e-bronze-to-api.yml around lines 88 - 94, Update the crazy-max/ghaction-github-runtime action reference in the workflow from the outdated v3 revision to the currently supported v4 revision, preferably pinned to its reviewed commit SHA. Preserve the existing workflow step and runtime-token exposure behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/e2e-bronze-to-api.yml:
- Around line 88-94: Update the crazy-max/ghaction-github-runtime action
reference in the workflow from the outdated v3 revision to the currently
supported v4 revision, preferably pinned to its reviewed commit SHA. Preserve
the existing workflow step and runtime-token exposure behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 9906fd16-d3e4-4281-af74-4e611ac1ca31
📒 Files selected for processing (1)
.github/workflows/e2e-bronze-to-api.yml
Problem
The
Build runner imagejob in the E2E workflow takes ~13.5 min on every PR run — a full Rust recompile of analytics + identity-resolution + jira-enrich — even on PRs that touch no backend code and leaveCargo.lockunchanged (e.g. #1926, where all runs rebuilt from scratch).BuildKit logs from those runs contain zero
importing/exporting cache manifeststeps: thetype=ghacache wired incompose/docker-compose.cache.ymlnever engages.Cause
The
type=ghacache backend needsACTIONS_RUNTIME_TOKEN/ACTIONS_CACHE_URL, which GitHub exposes only to JS actions.build-images.ymlworks becausedocker/build-push-actioninjects them; the E2E build runs./e2e.sh build(docker compose build) in a plainrun:step, so buildx finds no token and silently drops thecache_from/cache_toconfig.Fix
Add
crazy-max/ghaction-github-runtime@v3(by the buildx maintainer, built for exactly this) before the build step — it exports the ACTIONS_* runtime env to run steps.Expected effect
First run on this branch populates the cache; subsequent runs should show
importing cache manifest from gha,scope=e2e-*andCACHEDon the cargo dep layers, dropping the build job from ~13.5 min to ~2–4 min for PRs that don't touch backend code.🤖 Generated with Claude Code
Summary by CodeRabbit