Description

When Cirrus runner capacity is saturated, release/production build jobs compete equally with E2E builds, test runs, and fixture updates for runner slots. This means a time-sensitive release build can be queued behind dozens of E2E jobs triggered by PR pushes.

Cirrus Runners supports a binary priority system (regular and low-priority). This PR adds low-priority to all E2E/non-release Cirrus runner jobs so release pipeline jobs are serviced first during capacity saturation. When capacity is available, all jobs start immediately with no change in behavior.

Jobs deprioritized (E2E, non-release):

• build-android-e2e.yml - E2E Android APK build
• build-ios-e2e.yml - E2E iOS app build
• run-e2e-workflow.yml - E2E test execution (both platforms)
• update-e2e-fixtures.yml - Fixture export/update

Jobs kept at regular priority (release pipeline):

• build.yml - Production/release native build
• setup-node-modules.yml - Dependency setup for production builds
• upload-to-testflight.yml - TestFlight upload

The actionlint.yaml config already includes low-priority as a known self-hosted runner label (line 17).

Note: A similar but narrower change was attempted in #19091 (Sep 2025, iOS E2E only, 1 file) and reverted in #19379 (12 days later, no documented reason). This PR covers both platforms and all 4 E2E workflow files.

Part of MCWP-574 (PR 5 of 5).

Changelog

CHANGELOG entry: null

Related issues

Fixes: MCWP-574

Manual testing steps

Feature: Cirrus runner job priority for release pipeline

  Scenario: E2E jobs run normally when capacity is available
    Given Cirrus runner capacity is not saturated
    When an E2E workflow is triggered (build or test)
    Then the job starts immediately with no delay
    And the job completes successfully

  Scenario: Release jobs are prioritized during capacity saturation
    Given Cirrus runner capacity is near saturation with E2E jobs
    When a release/production build is triggered via build.yml
    Then the release build job is allocated a runner before queued E2E jobs
    And E2E jobs resume after runners free up

Screenshots/Recordings

N/A - CI pipeline change, no UI impact.

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.