Description

Splits the Runway release flow so that OTA updates and native binary builds are triggered by dedicated entry points rather than being auto-detected inside a shared core workflow. This PR is phase 1 (additive-only) — it introduces the new workflows alongside the existing ones without removing or renaming anything.

Why

Today the 4 per-platform Runway entry workflows (runway-{ios,android}-{production,rc}-workflow.yml) all go through runway-ota-build-core.yml, which compares OTA_VERSION in app/constants/ota.ts against the release tag to decide whether to dispatch push-eas-update.yml (OTA) or build.yml (native binary). We want release engineers to make that choice explicitly in Runway, and to combine iOS + Android into a single dispatch so the build-version bump only happens once per release.

Why two phases

Runway dispatches a workflow from the currently-selected release branch (no source_branch input is passed). That means the workflow file must exist on whichever branch Runway points at. Runway is a single configuration across all branches.

Because this PR can only be cherry-picked to release/7.75.0 and not to older active branches (release/7.73.x, release/7.74.x), the cleanup (deleting the 4 old per-platform workflows and renaming the core) has to wait until those older branches are retired — otherwise flipping Runway to the new names would break dispatches against them.

To keep this PR safe and reviewable without committing the organisation to the cleanup yet, the work is split into two phases:

• Phase 1 (this PR) — add the 5 new workflow files only; do not touch or remove anything existing.
• Phase 2 (follow-up PR, later) — delete the 4 old per-platform workflows, rename runway-ota-build-core.yml → auto-rc-ota-build-core.yml, and update build-rc-auto.yml. This will be opened only after release/7.73.x and release/7.74.x are retired and Runway has been flipped to the new workflow names.

What this PR adds

• runway-ota-resolve-context.yml — reusable workflow that resolves pr_number, base_ref, ota_version, and ota_bump from a given ref. Consumed by the new OTA workflows and designed to be consumed by the renamed core in phase 2.
• runway-production-builds.yml — bumps the build version once, then runs build.yml with platform: both for main-prod, and uploads the iOS IPA to TestFlight. No OTA, no Slack (matches today's production behaviour).
• runway-rc-builds.yml — same shape as above for main-rc, plus the existing Slack RC notification (matches today's RC behaviour).
• runway-ota-production.yml — pushes OTA to the production channel for both platforms via push-eas-update.yml (platform: all), then creates the v<OTA_VERSION> release tag via the existing runway-create-ota-production-tag.yml.
• runway-ota-rc.yml — pushes OTA to the rc channel for both platforms, plus the existing Slack RC notification.

What this PR does NOT change

• runway-ios-production-workflow.yml, runway-android-production-workflow.yml, runway-ios-rc-workflow.yml, runway-android-rc-workflow.yml — untouched; Runway can keep dispatching these as today.
• runway-ota-build-core.yml — untouched.
• build-rc-auto.yml — untouched; keeps calling runway-ota-build-core.yml as today.

Rollout notes

• Merge this PR to main, then cherry-pick to release/7.75.0 so the new workflow files exist on the first release branch that will use them.
• Runway config is not flipped yet. It keeps pointing at the 4 old per-platform workflow names until release/7.73.x and release/7.74.x are retired.
• The phase 2 cleanup PR will flip Runway and delete the now-unused old workflows.

Changelog

CHANGELOG entry:null

Related issues

Fixes:

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

Screenshots/Recordings

Before

After

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.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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.