ci: catch stale iOS bindings on pull requests - #365
Open
Imod7 wants to merge 2 commits into
Open
Conversation
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
1 participant
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.
Description
Adds a CI job that checks the committed iOS UniFFI bindings still match the Rust source in the pull request. Also moves the binding copy step out of
rebuild.shinto a script that both the local rebuild and the CI check call.Changes
ios/truapi-host/scripts/sync-bindings.sh(new). Copies the generated Swift bindings for the three uniffi namespaces into the package and strips trailing whitespace, which is whatrebuild.shdid inline.--checkcompares instead of writing, staging into a temporary directory so a failure leaves nothing behind.ios/truapi-host/scripts/rebuild.sh. Calls the new script instead of copying inline. Same result as before, but the check and the in place write cannot disagree about the file list or the normalization..github/workflows/ci.yml. Newios-bindingsjob runningmake uniffithensync-bindings.sh --check, registered inci-status. Runs onubuntu-latest, so no macOS runner, no Xcode and no iOS targets.ios/truapi-host/README.md,CLAUDE.md,.claude/skills/truapi-definition-of-done/SKILL.md. Document the bindings only refresh command and the CI check. The definition of done checklist gains an iOS bindings step, which it never had, so aHostCallbackschange can no longer pass the whole checklist with stale bindings.Why these changes
The committed UniFFI Swift bindings are build outputs. Any change to
HostCallbacks,NativeTrUApiCoreor the native mirror types makes them stale, and no CI job notices, so it lands green and surfaces later to whoever next runsrebuild.shor cuts an iOS release.What this catches and what it does not
truapi_server.swiftdoes notmake uniffiitself and compares its output against the committed filetruapi_server.swiftagree, but a hand written conformer such asStubHostCallbacksstill has the old method setxcodebuildon a macOS runnerThis PR guarantees the generated bindings match the Rust source. It does not guarantee the package compiles.
Testing
Before this PR: nothing regenerated or compared the iOS bindings, so stale bindings could not fail any check.
After this PR, run locally on base
aa878d1f: exit 0 on an unmodified checkout, exit 1 naming every stale file when a required method is added toHostCallbackswithout regenerating, exit 66 whentarget/uniffi-swift-outis missing.--checkmodifies no files, and write mode reproduces the committed bindings byte for byte. The job lands green on this base.