[NoQA] Fix three ways a version sync can fail or push a bad version to main by mountiny · Pull Request #97599 · Expensify/App

mountiny · 2026-07-31T17:57:51Z

Explanation of Change

Note

Extract syncVersions workflow shell into a script, which this was stacked on, has merged. This now targets main directly and its diff is only the hunks described below.

The full version sync path in .github/scripts/syncVersions.sh records the Mobile-Expensify submodule pointer unconditionally:

git add Mobile-Expensify
git commit -m "Update Mobile-Expensify submodule version to $target (sync recovery)"

When the versions differ but the App gitlink already points at Mobile-Expensify main, nothing is staged, so git commit exits 1. Under set -e that kills the job after the local version commit and before any push — so the sync silently accomplishes nothing and has to be re-run.

That state is reachable in practice: it is exactly what a previously half-completed sync leaves behind, where the submodule pointer got bumped but the versions did not.

The fix applies the same guard the submodule-only path already uses:

git add Mobile-Expensify
if ! git diff --staged --quiet; then
    git commit -m "Update Mobile-Expensify submodule version to $target (sync recovery)"
fi

This was deliberately left out of #97598 so that PR stayed a provably behavior-neutral refactor.

Two more failure modes in the same script are fixed here, for the same reason — they are behavior changes, so they do not belong in the refactor.

A TARGET_VERSION that isn't the Mobile-Expensify version reached main before failing. Only the App side is rewritten, so any other target fails the final verification. It did so after sync_full_version had committed and pushed that version to App main, leaving main claiming a version Mobile-Expensify never had. resolve_target_version now rejects it before anything is written.

Mobile-Expensify moving mid-run was reported as a failed sync. Verification refetches Mobile-Expensify main and compares it to the gitlink App now records. A deployer triggers this during a deploy, so Mobile-Expensify main can easily gain a commit while the sync runs — and a sync that recorded exactly what check pinned it to was then announced as a failure in #deployer. That one case is now a ::warning:: telling you to re-run; a gitlink this run never pinned is still a hard ::error::.

Accepting that case means the run reaches the Announce sync in Slack step, whose text claimed the submodule matches Mobile-Expensify main — which is exactly what this branch just established is not true. verify_sync therefore reports a SUBMODULE_MATCHES_REMOTE output and the announcement branches on it, so #deployer is told to run it again rather than that everything is aligned. That is the one hunk in .github/workflows/syncVersions.yml.

Fixed Issues

$ #88233
PROPOSAL: N/A

Tests

Check out this branch and run the suite on macOS. It lives in tests/tooling/ and runs under bun test, not Jest:
```
TZ=utc bun test --parallel --preload ./scripts/stubReactNative.js --preload ./tests/tooling/setup.ts ./tests/tooling/SyncVersions.test.ts
```
Verify all 19 tests pass. Four of them cover the three fixes:
- still syncs when the submodule pointer is already current
- rejects a target version that does not match Mobile-Expensify, without touching App main — a rewrite of fails verification when the target version does not match Mobile-Expensify, which passed for the wrong reason: it asserted the failure that happened after the bad version was pushed
- warns instead of failing when Mobile-Expensify main advances mid-sync
- fails verification when App main records a submodule commit this run never pinned — the other side of that branch, so downgrading it to a warning cannot swallow a real mismatch
Verify they are genuine regression tests. The fixes are committed, so put main's script back rather than stashing:
```
git checkout origin/main -- .github/scripts/syncVersions.sh
```
Re-run the command above and confirm exactly those four fail and the other 15 pass, then restore with git checkout HEAD -- .github/scripts/syncVersions.sh and confirm all 19 pass again.
Verify each failure in its unfixed state:
- Empty submodule commit: the output shows nothing to commit, working tree clean and a non-zero exit, with origin/main left without the version commit. Fixed, origin/main ends on Update version to 9.3.11-48 (sync recovery) and POST_SYNC_APP_VERSION is set.
- Bad TARGET_VERSION: origin/main receives Update version to 9.9.9-9 (sync recovery) before verification fails. Fixed, origin/main is untouched and the error names both versions.
- Mobile-Expensify moving mid-run: the run exits 1 with ::error::Submodule on App main ... still differs. Fixed, it exits 0 with ::warning::Mobile-Expensify main advanced to .... A gitlink this run never pinned still exits 1 on that same ::error::.
Run npm run shellcheck and verify it passes.
Read the Announce sync in Slack payload in .github/workflows/syncVersions.yml and confirm the success text says submodule matches Mobile-Expensify main. only when SUBMODULE_MATCHES_REMOTE is 'true', and otherwise tells the deployer to run it again. The suite asserts that output is 'true' after a clean submodule-only sync and 'false' after one where Mobile-Expensify moved mid-run.
Deployer validation: trigger the Sync E/App and Mobile-Expensify versions workflow manually from this branch (the Resolve the script to run step, now on main, makes that work before merge) and verify a normal sync — versions differ and the submodule pointer is behind — still produces both commits: Update version to <version> (sync recovery) followed by Update Mobile-Expensify submodule version to <version> (sync recovery).
Verify the TARGET_VERSION guard from the deployer side: trigger the same workflow with TARGET_VERSION set to something Mobile-Expensify is not on, and verify the run fails on ::error::TARGET_VERSION (...) must match the Mobile-Expensify version (...) with nothing pushed to main.

Verify that no errors appear in the JS console

Offline tests

Not applicable — this changes a GitHub Actions workflow script. There is no client-side behavior and no network state to vary.

QA Steps

Not applicable — no user-facing behavior changes. The workflow is a manual workflow_dispatch restricted to mobile deployers and is validated by triggering it directly (see step 5 in Tests), not on staging or production.

Verify that no errors appear in the JS console