fix(ci): stop a skipped retry job taking the whole deploy chain with it

[simonoppowa]

Merging #988 shipped nothing. Push run 33547853809 reported success with every check green, and the entire deploy chain was skipped:

ios-integration-tests / run     success
ios-integration-tests-retry     SKIPPED     ← skips on every healthy run
ios-integration-tests-result    success     ← has  if: !cancelled()
ios-package                     SKIPPED
ios-deploy                      SKIPPED
android-package                 SKIPPED
android-deploy                  SKIPPED
github-release                  SKIPPED

No v2.2.0 tag, no GitHub release, nothing to TestFlight, no AAB. The run was green, so nothing looked wrong.

Cause

2.2.0's own two-runner iOS integration change introduced it. ios-integration-tests-retry is skipped whenever the first runner passes — the normal case — and a skip travels the whole dependency chain, not one hop. ios-integration-tests-result steps out of the way with its own if: !cancelled(), but that exempts that job; the skip keeps going into the deploy jobs, whose if: contained no status function and so inherited GitHub's implicit success().

All five of ios-package's direct needs concluded success and it skipped anyway. The pipeline only deployed when the first iOS runner failed.

The A/B is clean: run 33243607505 fired byte-identical guards on the same event and deployed. The sole structural difference is that the package jobs then needed ios-integration-tests directly, before any job that skips on a healthy run existed upstream of them.

Ruled out with evidence: the if: | block scalar (byte-identical where deploy worked), the guard predicate (event=push, head_branch=main), reusable-workflow uses: jobs misbehaving in needs, and ios-podfile-lock-guard (skipped in both runs — it is in nobody's needs, which also shows the taint travels only along needs edges).

The fix

Including a status function drops the implicit success() and with it the inherited skip. That is also why each dependency now has to be asserted by hand: a bare !cancelled() would be strictly worse than the bug, because it would push an integration suite that failed on two independent runners straight to TestFlight and Play.

So every needs: entry gets an explicit result == 'success', and the comment on ios-package states the rules for keeping the two lists in step — == 'success' not != 'failure', !cancelled() not always(), and the event test kept as an AND-conjunct.

Verification

Outcome matrix, evaluated against the real conditions parsed out of the file:

case	ships
push main, first runner passes — the bug	✅ yes
push main, first failed, retry passed	✅ yes
workflow_dispatch on main	✅ yes
pull request, all green	❌ no
both iOS runners failed	❌ no
android-integration-tests / linux-checks / ios-build failed	❌ no
run cancelled mid-flight	❌ no
push to develop	❌ no
result job itself skipped	❌ no

actionlint 1.7.7 reports no new findings (8 pre-existing macos-26 unknown-label warnings on both baseline and patched). A structural check confirms all five guards mirror their needs: exactly, no dangling dependencies, and both atomicity comments intact.

Merging this is what deploys 2.2.0

The push to main runs the pipeline with the fixed guards. main is already at 2.2.0+63 and no v2.2.0 tag exists, so it cuts fresh.

Expect android-deploy to go green with the Play upload undone — that is the #942 tolerance, not success. Read the step summary, upload the AAB by hand, and read Play's warnings on the review step.

Not included, deliberately

workflow_dispatch has no ref test, and the trigger has no branch filter — a dispatch from any branch passes the guard and ships. This is not theoretical: run 26086317616 cut a release from integrate-cicd-deployment. Closing it is a one-line change to all five guards, but it belongs in its own commit so that reverting it cannot revert this fix.

[Copilot]

🟢 Approval recommended

The workflow changes correctly prevent transitive skip propagation while still enforcing that all required needs jobs must have succeeded before packaging, deploying, or cutting a release.

Pull request overview

This PR fixes a GitHub Actions deploy-chain regression where a skipped retry job (ios-integration-tests-retry) could propagate “skip” through needs: and silently prevent packaging/deploy/release jobs from running—even when all required checks were green.

Changes:

• Adds explicit !cancelled() plus per-needs result == 'success' checks to all deploy-gate jobs to avoid inheriting implicit success() skip propagation.
• Ensures deploy/release jobs only run when the workflow is a push to main or a workflow_dispatch, and only when every required upstream job actually succeeded.
• Documents the rationale and maintenance rules for keeping needs: and if: conditions in sync across the five gated jobs.

File summaries

File	Description
.github/workflows/default_workflow.yml	Makes deploy/package/release gating robust against transitive “skipped” propagation by using explicit status functions and per-need success assertions.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.