Repository navigation
app FFI re-pin: verify before pushing, commit through the contents API - #32477
Conversation
The repin job now runs check-app-ffi-pin.sh --verify-release before it pushes app-ffi-repin, and writes the pin through GitHub's contents API so the commit is the release App's, signed by GitHub. The review reconciler reviews such a PR on first sight and the lander lands it, so base is red on the FFI pin for about the build time instead of until someone notices (#32305, #31927, #32436). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-1fa4777434cab9ff131a
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Shipped in:
The feat-cmux-next push run https://github.com/manaflow-ai/cmux/actions/runs/41493651131 at f561b65 failed: cmux-next checks (god files, concurrency, crash safety, l10n). |
|
Review (codex gpt-6.1-sol high, sweep, via the review router; full diff from merge base d614f40 to this head): SHIP at 838226a [P2] [follow-up] .github/workflows/app-ffi-release.yml:563 - The job force-pushes |
…as lost (#32484) Review follow-up on #32477: the repin job force-pushes app-ffi-repin to the unpinned tip before the contents API write, so a failed write left the release unpinned until the next FFI push. Retry it up to five times; a write that landed but whose answer was lost is found on the branch. Agent-Session: https://cmux.com/deeplink/agent?id=aid-1fa4777434cab9ff131a Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Makes the app FFI re-pin land itself, through review, within about the release build time. #32305, #31927 and #32436 each left feat-cmux-next red on "Check the app FFI pin" for about an hour on 2026-11-02, while the re-pin PR (#32121) waited for someone to review and land it.
A PR can't re-pin itself:
cmux-app-ffi-<sha>releases publish only from a feat-cmux-next push (theffi-releaseenvironment and the tag ruleset). So the fix is to shorten the wait after the push:check-app-ffi-pin.sh --verify-releasebefore it pushesapp-ffi-repin. The pinned checksum has to be the published one, and the FFI sources have to match the release's SOURCE_SHA tree. A base that has since gained newer FFI sources fails here and waits for the newer publish.app-ffi-repinon first sight, but only when it changesPackage.swiftalone in such commits. The lander then lands it on that receipt.--input), because Package.swift's base64 (about 131 KB) is past Linux's 128 KiB limit for one argument.No permission changes: the job already mints
contents: writefor this App.Changelog
none
Observed / Not run
python3 tests/test_app_ffi_release_workflow.py: 10 tests OK on the head. The new assertions fail on base (verify before push, a contents API PUT with--input, nogit commit).Agent session: agent session
🤖 Generated with Claude Code
Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Makes the app FFI re-pin land itself automatically within about the release build time, instead of leaving
feat-cmux-nextred on "Check the app FFI pin" for about an hour while waiting for a reviewer.check-app-ffi-pin.sh --verify-releasebefore pushing, so the pinned checksum must be the published one and the FFI sources must match the release's SOURCE_SHA tree.--input) because Package.swift's base64 exceeds Linux's 128 KiB argument limit.Changelog
none
Written for commit 838226a. Summary will update on new commits.