chore(INFRA-3591): temp Bitrise RN cache + iOS E2E smoke POC

[bsgrigorov]

Description

Adds temp-bitrise-ios-rn-e2e.yml: Bitrise iOS build using the same React Native / Bitrise Build Cache path as the RN-only POC, then runs iOS E2E smoke via run-e2e-smoke-tests-ios.yml with use_bitrise_runner: true. Schedule is :30 UTC hourly to stagger from the RN-only workflow (:00). Also aligns temp-bitrise-ios-kv.yml with actions/checkout@v6, actions/cache@v5, actions/cache/restore@v5, and actions/upload-artifact@v6, and passes use_bitrise_runner through stake-ios-smoke, wallet-platform-ios-smoke, and money-ios-smoke so Bitrise benchmarking is consistent when the flag is set.

Branch: chore/INFRA-3591-bitrise-rn-cache-e2e-poc (separate from the RN-only and KV-only POC branches.)

Changelog

CHANGELOG entry: null

Related issues

Fixes: INFRA-3591

Manual testing steps

Feature: Bitrise RN cache + E2E temp workflow

  Scenario: Workflow runs on label or schedule
    Given a non-fork PR has label bitrise-poc or the hourly :30 UTC schedule fires
    When the temp Bitrise RN+E2E workflow runs
    Then the build job completes and E2E smoke jobs can consume the uploaded iOS artifact

Screenshots/Recordings

N/A — CI / workflow-only change.

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.

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

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.

---

Note

Medium Risk
Medium risk because it changes where iOS E2E jobs run (Bitrise self-hosted runner group) and introduces new scheduled POC workflows that could impact CI capacity or job behavior when enabled.

Overview
Adds an opt-in Bitrise execution path for iOS E2E smoke tests. run-e2e-smoke-tests-ios.yml and the shared run-e2e-workflow.yml now accept use_bitrise_runner and, when enabled, run iOS shards on the temp-bitrise-runners runner group (with a Bitrise pool label) instead of the Cirrus macOS runner.

Improves Bitrise runner compatibility. When use_bitrise_runner is set, the E2E workflow adds a step to fix Bitrise/Vagrant home/toolcache paths by creating /Users/runner -> /Users/vagrant and setting RUNNER_TOOL_CACHE/RUNNER_TEMP.

Adds temporary Bitrise POC workflows for benchmarking. Introduces temp-bitrise-ios-rn-e2e.yml (Bitrise React Native build cache + iOS E2E app build, then runs iOS smoke tests on Bitrise) and temp-bitrise-ios-kv.yml (KV-cache-only build POC), and updates actionlint config to allow Bitrise runner labels.

^{Reviewed by Cursor Bugbot for commit af54674. Bugbot is set up for automated code reviews on this repo. 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: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
All 5 changed files are purely CI/CD infrastructure changes with zero impact on application code:

1. run-e2e-smoke-tests-ios.yml: Adds a use_bitrise_runner boolean input that propagates to all iOS smoke test jobs. This is a runner routing parameter — it doesn't change what tests run or how the app behaves.

2. run-e2e-workflow.yml: Adds use_bitrise_runner input and updates the runs-on expression to conditionally route to Bitrise self-hosted runners. Also adds a Vagrant path symlink fix step for Bitrise runner compatibility. This is infrastructure plumbing only.

3. temp-bitrise-ios-kv.yml (new): Explicitly marked as a TEMPORARY POC workflow (INFRA-3591) for benchmarking Bitrise KV cache. NOT part of the CI gate. The E2E smoke test job is commented out in this file.

4. temp-bitrise-ios-rn-e2e.yml (new): Another TEMPORARY POC workflow for benchmarking Bitrise RN build cache + E2E. Also NOT part of the CI gate. Only triggers on bitrise-poc label or schedule.

5. .github/actionlint.yaml: Adds Bitrise runner pool labels to the allowed self-hosted runner list for YAML linting.

Why no E2E tests are needed:

• No application source code was modified (no components, controllers, hooks, screens, or test logic)
• The temporary workflows are POC benchmarking tools gated behind a bitrise-poc label — they don't affect the standard CI gate
• The use_bitrise_runner parameter defaults to false, meaning existing CI behavior is completely unchanged unless explicitly opted in
• These changes cannot break any existing E2E test logic or user flows
• Running E2E tests here would validate the app, not the CI infrastructure changes themselves

Performance Test Selection:
No application code changes were made. All changes are CI/CD infrastructure (workflow files, runner routing, caching strategies). There is no impact on UI rendering, state management, data loading, app startup, or any other performance-sensitive code paths. 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