ci(INFRA-3596): phase4: add workflow_dispatch to build-ios-e2e, update run-e2e-api-specs runs-on

[XxdpavelxX]

Task: https://consensyssoftware.atlassian.net/browse/INFRA-3596

Description

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.

---

Note

Medium Risk
Changes CI runner selection and caching behavior across multiple iOS workflows; misconfiguration could break builds/uploads or reduce cache effectiveness, but no product/runtime code is affected.

Overview
Adds a runner_provider input (with workflow_dispatch choice) across iOS workflows to optionally run jobs on Namespace runners instead of GitHub/Cirrus defaults.

Routes runner_provider through build-and-upload-to-testflight into build.yml/upload-to-testflight, updates several jobs’ runs-on expressions (including fixture update and BrowserStack upload flows), and adjusts iOS E2E caching so Namespace runs use namespacelabs/nscloud-cache-action while skipping Cirrus Xcode derived-data cache steps.

^{Reviewed by Cursor Bugbot for commit 856c6c5. 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.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e7405cc. Configure here.}

[bsuv]

Follow-up from the recent Namespace call: their nscloud-cache-action ships a built-in cocoapods preset (and 24 others) that may eliminate the /Volumes/cache/<path> symlink workaround on this PR.

Worth A/B-testing before merge:

- uses: namespacelabs/nscloud-cache-action@15799a6b54e5765f85b2aac25b3f0df43ed571c0  # v1.4.3
  with:
    cache: cocoapods

vs. the current explicit path: list. If the preset behaves cleanly, we'd be able to:

1. Drop the custom path-mount entries for ios/Pods and ~/Library/Caches/CocoaPods.
2. Remove the stale DerivedData/build/Pods clear step.
3. Inherit whatever path coverage / ignore-glob tuning Namespace bakes into the preset upstream.

Reference: https://namespace.so/docs/reference/github-actions/nscloud-cache-action#cache. CocoaPods was specifically called out as "helpful right away" by the Namespace team.

A single dispatch with runner_provider=namespace against this branch should be enough to confirm. If the preset doesn't cover everything we need on this iOS path, the current explicit approach is the right fallback.

[XxdpavelxX]

@bsuv You're right. The preset is sufficient on its own, including without
the clear step. I tested with two A/B dispatches against the namespace-runner-trial4 branch:

- Test A (preset + clear step):    run 25688771799 — passed in 24 min                                                          
- Test B (preset only, no clear):  run 25690563669 — passed in 21 min                                                          

Both produced real builds, so the cocoapods preset
appears to handle whatever combination of path coverage and write-policy
prevents the stale-state failure modes. Adopted in commit f37c5cc.

[tommasini]

What's the reason for we need to add a dispatch?

[XxdpavelxX]

Fair point, added it for trial iteration speed during Phase 4 validation. It's useful during trial, not really needed once this lands. Removed

[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:
All 6 changed files are GitHub Actions workflow files with purely CI infrastructure changes. The changes add a runner_provider input parameter to multiple workflows, enabling an alternative Namespace CI runner provider alongside the existing runners. Key points:

1. No app source code changes - no application logic, components, controllers, or test logic was modified
2. Backward compatible - runner_provider defaults to current, preserving all existing behavior unchanged
3. Additive only - new runner path added without modifying existing runner paths
4. CI plumbing - changes affect where CI jobs run (runner selection), not what they test or how the app behaves
5. Namespace-specific additions: CocoaPods cache action for Namespace runners, conditional Xcode cache skipping for Namespace runners

These workflow changes do not affect any E2E test functionality, app behavior, or test infrastructure logic. No E2E test tags are needed to validate these changes - they are validated by the CI system itself when the workflows execute.

Performance Test Selection:
No app source code, performance-sensitive components, or rendering logic was changed. These are purely CI workflow infrastructure changes affecting runner selection only. No performance impact on the app.

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