Description

Remove OTA publishing and release-tag creation from the automated/Runway CI flows. OTA updates are now published and tagged manually in Runway, so CI only needs to detect OTA bumps (to skip native builds) and otherwise build.

Changes

auto-rc-ota-build-core.yml (Auto RC build/OTA core)

• Removed the trigger-ota job (no longer pushes EAS OTA updates via push-eas-update.yml).
• Removed the validate-ota-pr job (only existed to guard the OTA push).
• Removed the create-ota-production-tag job and the create_production_ota_tag + ota_channel inputs.
• Kept OTA detection: resolve-context still runs and trigger-build remains gated on ota_bump != 'true', so OTA-only branches skip the native build instead of building.
• Tightened permissions from contents: write + actions: write + pull-requests: read + id-token: write down to contents: read + pull-requests: read + id-token: write.

runway-ota-production.yml (Runway OTA Production)

• Removed the create-ota-production-tag job — the v<OTA_VERSION> tag is now created manually in Runway.
• Tightened permissions contents: write → contents: read (write was only needed to push the tag).
• Updated header comment + source_branch input description.

runway-create-ota-production-tag.yml

Deleted — it was the reusable tag-creation workflow and is no longer referenced by any caller after the changes above.

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.