fix(ci): assign unique build versions for nightly exp and rc builds

[tommasini]

Description

The nightly build workflow bumped the version only once and then built both main-exp and main-rc from the same commit. Since both share the same iOS bundle ID (io.metamask.MetaMask — both are METAMASK_BUILD_TYPE: main), TestFlight requires a unique CFBundleVersion per upload. The second upload would be rejected with a duplicate build number error.

This fix introduces a two-step version bump strategy:

1. Call the external version generator once → version N (for exp)
2. Locally increment to N+1 and commit (for rc)

Both builds still run in parallel after their respective bumps, so no meaningful latency is added.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

N/A — CI-only workflow change. Verify by triggering the nightly build workflow and confirming both exp and rc builds upload to TestFlight successfully with distinct build numbers.

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Made with Cursor

---

Note

Medium Risk
Changes the nightly GitHub Actions workflow to perform an additional version-bump commit and force-push before the RC build, which could disrupt nightly builds if the bump/push sequence fails or races.

Overview
Updates nightly-build.yml to split the single version bump into two jobs: an exp bump via update-latest-build-version.yml, followed by an RC-only bump that increments the exp build number (N→N+1), commits the versioned files, and force-pushes to the nightly branch.

The exp and rc build jobs are rewired to build from their respective bump commits (so TestFlight uploads no longer collide on CFBundleVersion).

^{Written by Cursor Bugbot for commit f223098. This will update automatically on new commits. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 95%

click to see 🤖 AI reasoning details

E2E Test Selection:
The only changed file is .github/workflows/nightly-build.yml, which is a pure CI/CD workflow change. The modification splits the single bump-version job into two separate jobs (bump-version-exp and bump-version-rc) to ensure unique CFBundleVersion values when uploading both exp and rc builds to TestFlight (which requires unique bundle versions per upload).

This change:

1. Does NOT touch any application source code
2. Does NOT modify any test files or test infrastructure (no changes to tests/, page-objects, fixtures, etc.)
3. Does NOT affect any E2E test configuration or Detox setup
4. Only affects the nightly build pipeline's version bumping strategy
5. Has zero impact on app behavior, UI, controllers, or user flows

Since this is purely a CI/CD infrastructure change with no impact on the application code or test infrastructure, no E2E test tags need to be run. The nightly build workflow itself is not part of the PR E2E test pipeline.

Performance Test Selection:
The change is limited to the nightly build CI workflow (version bumping strategy). No application code, UI components, state management, or performance-sensitive paths were modified. Performance tests are not warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Cal-L]

Lgtm