fix(mobile): accept a release branch other than fork/integration - #344
Merged
Conversation
The first fork/dev merge dispatched mobile releases and EAS production failed at "Resolve approved integration source". Both mobile workflows check out a hardcoded `ref: fork/integration` and then assert the requested SHA is an ancestor of that checkout. A fork/dev SHA is not contained by fork/integration, so the assertion rejected it. Add a release_branch input defaulting to fork/integration, use it for the checkout, and compare the overlay condition against it instead of the literal. Defaulting preserves today's behaviour for any manual dispatch that omits it. fork-ci.yml passes release_branch alongside the ref it already passed. Passing one without the other is the trap: the workflow file would come from fork/dev while the product checkout stayed on fork/integration, which is exactly the failure above. This is the same hardcoding as the dispatch side fixed in #343 — it was simply one workflow further along, and only observable once a real fork/dev merge dispatched a release. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
patroza
added a commit
that referenced
this pull request
Aug 6, 2026
The first `fork/dev` sync merge (`ae4719b1c`, #345) passed **every required check** and still ended as a **failed run**: ``` Check ✅ Test ✅ Mobile Native Static Analysis ✅ Release Smoke ✅ Classify Deployment Scope ✅ Dispatch Mobile Releases ❌ HTTP 422: Unexpected inputs provided: ["release_branch"] ``` Because the deploy poller only promotes a SHA whose `fork-ci` run **concluded success**, that one failure blocked server, Discord, desktop and VS Code deployment of `ae4719b1c` entirely. The guest is still sitting on `21badd04e`. ## Cause [#344](#344) added the `release_branch` input **declaration** to `mobile-eas-production.yml`, but for `mobile-eas-development.yml` it only rewrote the *usages* — leaving the file referencing `inputs.release_branch` without declaring it. Production dispatch succeeded; development was rejected. The validation in that PR printed the default for production and nothing for development. That was the evidence, and it was read past. ## Change Declare the input with the same `fork/integration` default, so a manual dispatch that omits it behaves exactly as before. ## Validation Rather than eyeball it again, all three workflows are now checked for `inputs.*` references with no matching declaration: ``` fork-ci.yml | declared: checkout_ref | undeclared: none mobile-eas-production.yml | declared: mode,platform,message,runtime_version,sha,release_branch | undeclared: none mobile-eas-development.yml | declared: platform,runtime_version,sha,release_branch | undeclared: none ``` ## Separate design question, not fixed here **Should a release-dispatch failure invalidate a validation verdict?** `Dispatch Mobile Releases` performs a *release action*; the other five jobs *validate the SHA*. Mixing them in one run means any dispatch hiccup — a 422, a transient API error — marks the SHA unapprovable and stalls the whole fleet, which contradicts the handover doc's own rule that per-target release status is recorded independently and that one target's failure must not hold back the others. Two options, both one-liners: - `continue-on-error: true` on `dispatch_mobile_releases` — run concludes success, the failed job stays visible, mobile status is tracked by the EAS workflows anyway. - Move the dispatch into its own `push`-triggered workflow so `fork-ci`'s conclusion means "this SHA is valid" and nothing else. I did not apply either, because weakening the deploy-approval signal is a policy call. Say which you want and I'll do it. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
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.
Found by the first real
fork/devmerge. #343 merged,the push run went green,
Dispatch Mobile Releasesfired — and then EAS productionfailed at Resolve approved
integration source.
Cause
Both mobile workflows check out a hardcoded ref and then assert containment:
A
fork/devSHA is not contained byfork/integration, so the assertion rejected it. Same class ofhardcoding #343 fixed on the dispatch side — just one workflow further along, and only observable
once a real
fork/devmerge dispatched a release.Change
release_branchinput on both mobile workflows, defaulting tofork/integrationso any manualdispatch that omits it behaves exactly as before.
${{ inputs.release_branch }}; the "overlay deploy tooling" condition comparesagainst it instead of the literal.
fork-ci.ymlpassesrelease_branchalongside the--refit already passed.Passing one without the other is the trap worth naming: the workflow file would come from
fork/devwhile the product checkout stayed on
fork/integration— precisely the failure above.Validation
release_branchdefault confirmed asfork/integration.vp fmt --checkclean across.github/workflows/.fork/devmerge thatclassifies
mobile=true— this PR's own merge should do it, since it touches.github/workflows/**. Worth watching that run rather than assuming.Note on the first dispatch
That run classified every component as changed because no previous successful
fork/devpush runexisted to diff against — the documented conservative fallback. Subsequent merges diff against the
prior green
fork/devSHA and should scope normally.Co-authored by @patroza
opened by Patrick Roza in chat thread Discord · Discord · T3