Build chromium images on the shared buildx builder - #358
Conversation
Both image jobs ran on 2-core hosted runners with type=gha layer caching. Chromium layers are large, so mode=max churned against the repo's 10GB Actions cache quota and builds swung 79s to 700s depending on eviction luck. Move the jobs to the self-hosted pool and attach to the persistent deft-shared builder, whose local layer store replaces the gha cache entirely. Docker Hub push behavior and tags are unchanged; the e2e job pulls the same images as before. The pristine-context reset and isolated Docker config mirror kernel/kernel's auth-flow-simulator workflow, which pioneered this setup: persistent runner workdirs carry file modes that bust COPY cache keys, and the shared BUILDX_CONFIG path is the one root-run CI from other repos cannot clobber. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e7248be. Configure here.
The docker jobs now run on the persistent self-hosted pool, and this is a public repo: a fork PR must not execute on those runners. Fork PRs previously failed at Docker Hub login (forks get no secrets); with the guard they and the dependent e2e job skip instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
tnsardesai
left a comment
tnsardesai
left a comment
There was a problem hiding this comment.
agent review flagged this blocker! I haven't checked if its possible yet but comment seems valid
.github/workflows/chromium-headful-image.yaml:8-12and.github/workflows/chromium-headless-image.yaml:8-12— the newifguard is part of the PR-controlled workflow, so a fork can remove it in the same change and request theself-hostedlabel directly. Approval gates reduce exposure but do not make the persistent runner safe after approval. This needs enforcement outside PR-controlled code—such as runner-group access restricted to a trusted default-branch workflow—or fork PRs must have no access to this self-hosted runner pool.
|
Addressing the blocker with a control outside PR-controlled code, now in place: The org Actions policy is set to require approval for workflow runs from all external contributors. That lives in org settings, a fork cannot edit it, and it means fork code has no execution path on any runner (deft included) unless a maintainer explicitly approves that specific run. Combined with the job-level guard (which covers the approved-but-unmodified case), fork PRs get: no auto-execution, and skipped builds even when approved. 
On the suggested runner-group workflow restriction: we looked at it, and it cannot serve this use case. Pinning the group to refs/heads/main also rejects same-repo pull_request jobs, because PR runs execute from merge refs, which would kill the PR build path this PR exists to speed up. Wildcard refs only block net-new workflow files, not edits to the listed ones. Remaining residual: a maintainer approving a run from a fork that edited the workflows. Two things bound it: this repo has never merged a fork PR (0 of the last 29), and the working norm is that fork runs do not get approved. If we want that mechanized, a small pull_request_target auto-closer (executes the base repo's copy, forks cannot modify it, runs on hosted only) would close fork PRs before an approval is ever possible. Happy to ship that as a follow-up; it does not need to gate this PR. Does that clear the blocker? |
2 participants
Moves the headful and headless image builds from 2-core hosted runners to the self-hosted pool, attached to the persistent deft-shared buildx builder (same setup as kernel/kernel's image builds). The builder's local layer store replaces type=gha caching, which was churning against the repo's 10GB Actions cache quota and making build times a lottery (79-700s). Docker Hub push, tags, and the e2e flow are unchanged.
Measured on this PR's own CI (run 33197223789):
The pristine-context reset and isolated Docker config are ported from kernel/kernel's auth-flow-simulator workflow; .github/buildkitd.toml is the recreate-fallback config.
Note
Medium Risk
Changes CI infrastructure (self-hosted runners, shared builder, fork skip) and image build caching; runtime images and push tags are unchanged but fork PRs no longer run these image/e2e jobs.
Overview
Moves chromium-headful and chromium-headless Docker builds from GitHub-hosted runners to self-hosted runners using the persistent
deft-sharedBuildx builder, matching the pattern used elsewhere in the org.Caching and config: Drops
type=ghacache import/export in favor of the builder’s local layer store. Adds.github/buildkitd.tomlas a recreate fallback (longer retention for cache mounts/local context, 150GB storage cap with 100GB free-space floor). Buildx setup pinsdeft-shared,cleanup: false, and that config file.Runner hygiene: Before build, jobs reset the checkout to a pristine context (clean + normalized file modes) so COPY cache keys stay stable on persistent workspaces. They also use a temp
DOCKER_CONFIGwhile pointingBUILDX_CONFIGat~/.docker/buildx-ciso registry login stays isolated without losing the shared builder.Fork PRs: The docker job is skipped when the PR head is from a fork (no secrets and no self-hosted pool), which propagates to dependent e2e via
needsinstead of failing at Docker Hub login.Reviewed by Cursor Bugbot for commit 5d3eb63. Bugbot is set up for automated code reviews on this repo. Configure here.