ci(native): add force input to rebuild a drifted artifact key#11
Merged
Conversation
The `Already published?` guard only checks that the asset exists, so once a key's published asset drifts from the committed manifest there is no way to republish it: every dispatch sees the object, skips the build, and the EAS `eas-build-pre-install` hook keeps failing its checksum verify. That drift happened for chat_mls_coreFFI-ios-7e4fdcc9abc3f190: a locally built xcframework was uploaded over the CI-published one. Same source key, different bytes (the binaries are non-reproducible), so the consumer can never verify. Dispatch with force=true to bypass the guard and rebuild + republish, which also refreshes the committed manifest back into lockstep with the asset. Non-dispatch events leave `inputs.force` null, so push/PR behaviour is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018bbPAiJXZSrCaGTMZERmKX
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The iOS EAS build has been failing in
eas-build-pre-install, before any compile:The key is correct and the fetch succeeds — the published asset just doesn't match the committed manifest. In the tarball, headers/plists/modulemaps verify OK; only the two Mach-O binaries and the top-level
Info.plistfail. Same source, different compile.What happened: CI run 28983282244 built, uploaded, and committed the manifest in
b8bf0faon Jul 8 23:54. The R2 object'sLast-Modifiedis Jul 9 09:50 — ten hours later, with no workflow run in between. A locally built xcframework was uploaded over the CI-published one (confirmed: the localios-arm64binary hashes2a2f899c76e8dc…, byte-identical to what R2 serves, and both fail the committed manifest).Because the binaries are non-reproducible, the same source key yields different bytes per compile — so the consumer can never verify, and every iOS EAS build fails until the two sides are realigned.
The trap
Already published?only checks existence (curl -fsI). Once a key drifts, it's unrepairable by dispatch: the guard sees the object, skips the build, and nothing republishes. The only escape was deleting the R2 object by hand.What this does
Adds a
forceboolean toworkflow_dispatchthat bypasses the guard on both jobs.aws s3 cpoverwrites in place, and the commit step refreshes the manifest back into lockstep with the asset.inputs.forceis null on push/PR events, so those paths are unchanged. Passed viaenv:rather than interpolated intorun:.Follow-up (not in this PR)
Two things would stop this recurring:
aws s3api put-object --if-none-match "*"so an upload against an existing key fails loudly instead of poisoning it.Local
build:iosrewriting the committed manifest is the mechanism the drift travels through; worth a guard there too.