Repository navigation
ci(android): wait for the producer's platform job and keep the fallback build alive - #2261
Merged
Merged
Conversation
…ck build alive Classify the fixture producer by its platform job (Android Release / iOS Release) instead of the run's aggregate status: the run flickers to "queued" in the gap between its fingerprint job and its platform job, which made the Android consumer bail into an inline build almost instantly (run 33550746596). Both queued and in_progress on the platform job now mean keep waiting. Raise android.yml's wait-for-artifact-seconds to 1800s (matching the iOS workflow's own budget) so a real wait can play out now that the premature "queued" bail is gone. Raise the Android Gradle daemon heap (org.gradle.jvmargs=-Xmx4g) for both the producer build and the inline fallback build: the producer's own Android Release job OOM'd in :app:compileReleaseArtProfile (run 33728318738), and both prior inline fallbacks OOM'd in :app:mergeDexRelease.
Contributor
Size Report
npm unpacked components
Startup median (7 runs, lower is better):
Top changed chunks: no changes in the largest emitted chunks. Top changed packed filesNo changed packed files. |
Member
Author
|
READY at Clean exact-head CI. Producer state is keyed to the exact run plus platform job; the queued path exhausts its bounded wait then falls back, unknown platforms fail closed, and targeted regressions cover the change. The 30-minute Android wait is an accepted operational tradeoff, not a blocker. |
thymikee
added
the
ready-for-human
Contributor
|
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.
Summary
The Android fixture lookup classified producer readiness by the whole workflow run's aggregate status, which flickers to
queuedbetween the fingerprint job finishing and theAndroid Releasejob starting — the consumer treatedqueuedas "give up" and bailed into an inline Gradle build almost instantly (run 33550746596).trusted-artifact.mjs'sproducer-statenow classifies by the producer's own platform job (Android Release/iOS Release, viaactions/runs/{id}/jobs), not the run's aggregate status, and takes an explicitplatformargument.fetch-artifact.shtreatsqueuedlikein_progress(keep polling) instead of bailing.android.yml'swait-for-artifact-secondsrises 600s → 1800s, matchingios.yml.org.gradle.jvmargs=-Xmx4g: the producer OOM'd in:app:compileReleaseArtProfile(run 33728318738), prior fallbacks OOM'd in:app:mergeDexRelease.Trust rule (exact head SHA or default-branch push) unchanged.
Validation
trusted-fixture-artifactnode:test file andpnpm test:fixture-fallback— pass.pnpm check:quick,pnpm check:fallow,pnpm check:gate-manifest,pnpm format:check— clean.AssertionError: expected 'queued' to equal 'in_progress'; reverting thequeued/in_progressmerge gaveFAIL: ios queued producer state bailed instead of waiting out its budget.Both restored green.Tradeoffs / follow-ups
Left the shared action's
wait-for-artifact-secondsdefault at0:replays-manual.yml'smanual-androidjob relies on it withrequire-artifact: trueunder a 15-minute timeout; a global bump would turn a fast failure into a confusing timeout.