ci: verify the ferric Apple binaries depend on weak-node-api - #409
Open
kraenhansen wants to merge 2 commits into
Open
ci: verify the ferric Apple binaries depend on weak-node-api#409kraenhansen wants to merge 2 commits into
kraenhansen wants to merge 2 commits into
Conversation
Extends the "Test ferric Apple triplets" job so it doesn't only assert which architectures were produced, but also that each produced binary actually links the weak-node-api framework, catching regressions where a triplet builds but drops the dependency. The expected number of `@rpath/weak-node-api.framework/weak-node-api` lines is derived from the otool output itself — `otool -L` prints one header per file, or one per architecture for fat files — rather than hard-coded, so it doesn't rot when a triplet is added or dropped. Also renames lipo-info.txt to lipo-output.txt for symmetry with the new otool-output.txt, and uploads both as artifacts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SrPdjhQ6aG949mVDDaiT2U
The first CI run of this check reported 8 dependencies across 10 binary slices. The two misses were the macOS slices: macOS frameworks use the versioned bundle layout, so weak-node-api's install name there is @rpath/weak-node-api.framework/Versions/0.1.1/weak-node-api where iOS, tvOS and visionOS get the flat @rpath/weak-node-api.framework/weak-node-api Both are a genuine dependency on the framework, so match the optional "Versions/<version>/" component rather than only the flat form. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SrPdjhQ6aG949mVDDaiT2U
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.
Redo of #336 (and the #335 it was stacked on), rebased onto
nextand with the check actually verified against a real CI run instead of guessed.To help increase confidence and avoid future regressions, the "Test ferric Apple triplets" job now checks the
otooloutput too, so it doesn't only assert which architectures were produced but also that every produced binary actually linksweak-node-api.framework.Changes
otool -Lalongsidelipo -infoon the built framework binaries, and upload both as artifacts.weak-node-api.framework.lipo-info.txttolipo-output.txt, for symmetry with the newotool-output.txt.Why not a hard-coded count
#335 hard-coded
-ne 4; #336 changed it to7, reasoning "3 fat binaries + 4 thin binaries". Both are wrong, and in two independent ways that a hard-coded number can't express:otool -Lprints one header — and therefore one dependency list — per architecture slice for a fat file, not one per file. With 3 fat (2 archs each) + 4 thin binaries there are 10 dependency lists, not 7.So the expected count is now derived from the
otooloutput itself by counting its header lines. It can't drift out of sync with thelipofixture above it, and it doesn't need updating when a triplet is added or dropped. The step echoes what it found, so the numbers are visible in the job log on success as well as failure.What the verification run turned up
The first run of this check on CI reported:
The two misses were the macOS slices. macOS frameworks use the versioned bundle layout, so the install name there is
where iOS, tvOS and visionOS get the flat
Both are a genuine dependency on the framework, so the pattern now accepts an optional
Versions/{version}/path component. This is exactly the sort of detail a hard-coded4or7would have papered over — with7the check would have passed while two slices went unmatched, and the number would have looked "verified".After the fix, CI reports: