ci: smoke both iOS flavors on a real device - #9
Merged
Conversation
real-device-smoke-ios fetched the nodejs-mobile-ios artifact -- the full flavor -- and lite's only device-class coverage was curated-tests-ios on a simulator. A simulator is a macOS process and is not subject to the address-space limits a real iOS process is, so that pairing cannot tell you whether a flavor boots on hardware. 24.19.0-1 shipped an iOS lite build that aborts during Isolate init on every physical device with every simulator leg green. Give the iOS leg a flavor matrix, defaulting to both, in the shape ios-simulator-tests.yml already uses: an ios_flavors JSON-array input, fromJSON'd into strategy.matrix, and FLAVOR_SUFFIX selecting the per-flavor artifact. fail-fast is off because which flavors boot is the signal, and the build tag carries the flavor so the two BrowserStack builds are distinguishable. This only costs device minutes on release and dry-run pushes, where the job is already gated -- it never runs on a PR. Android stays full-only; its lite flavor has the same blind spot but the emulator is a closer proxy there, and widening it is a separate call. Publish already needs: this job, so a lite build that cannot start on hardware now blocks the release instead of shipping.
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.
real-device-smoke-iosfetches thenodejs-mobile-iosartifact — the full flavor — and lite's only device-class coverage iscurated-tests-ios, which runs on a simulator. A simulator is a macOS process and is not subject to the address-space limits a real iOS process is, so that pairing cannot tell you whether a flavor boots on hardware.That is not hypothetical: 24.19.0-1 shipped an iOS
litebuild that aborts duringIsolateinit on every physical device, with every simulator leg green. #8 fixes the build; this closes the hole that let it out.What changes
The iOS leg gets a flavor matrix defaulting to both, in the shape
ios-simulator-tests.ymlalready uses — anios_flavorsJSON-array input,fromJSON'd intostrategy.matrix, andFLAVOR_SUFFIXselecting the per-flavor artifact (nodejs-mobile-ios/nodejs-mobile-ios-lite, both of which already carryinclude/, so the crc-native addon build needs no change).fail-fastis off: which flavors boot on hardware is the signal, so both should report rather than one cancelling the other. The build tag gains the flavor (sha-<sha>-<flavor>) because both legs upload to the same BrowserStack project and an untagged pair is indistinguishable in the dashboard.publishalreadyneeds:this job, so a lite build that cannot start on a device now blocks the release rather than shipping.Cost
None on PRs — the job is gated on
release-checkand only runs on release andrelease-dryrun:pushes. On those it adds one iOS device build, on the same single-device default (iPhone 15-17). That is the one genuinely metered resource here, so to be explicit about the trade: the flavor a consumer actually ships is the one that has to be proven on hardware, and full-only coverage bought us a broken release.Scope
Android stays full-only. Its lite flavor has the same structural blind spot — it is emulator-tested only, and it is pointer-compressed — but an emulator is a much closer proxy to an Android device than a simulator is to an iPhone, so widening it is a separate call rather than something to slip into this PR.
Sequencing
Merge after #8. Nothing breaks if this lands first — the job does not run on a plain push to
recipe, since the version of record is still tagged andrelease-checkreports no release — but the next release run would go red on the new lite leg until #8 is in. Verified withactionlint: no new findings (the one it reports is pre-existing, in the Android gradle step).