Description

Introduces a single source of truth for build configuration (.github/builds.yml) and supporting scripts so we can later migrate from Bitrise to GitHub Actions without changing behavior today.

What was added

• .github/builds.yml – Defines all build variants (main-prod, main-rc, main-test, main-e2e, main-exp, main-dev, flask-prod, flask-test, flask-e2e, flask-dev) with env, secret mappings, code fencing, and remote feature flag defaults.
• Scripts – validate-build-config.js (YAML validation), apply-build-config.js (load config and set env), set-secrets-from-config.js (map GitHub Secrets to env from config), and verify-build-config.js (compare Bitrise env with builds.yml).
• Bitrise “Phase 1.5” step – Runs verify-build-config.js --verbose in selected workflows. This step is skippable and runs with || true, so it never fails the build. It only logs comparisons between Bitrise env and builds.yml for validation.

Important: no impact on existing workflow or Bitrise

• Existing Bitrise env vars, remapping, and build steps are unchanged.
• No step is removed or altered except for adding the optional Phase 1.5 verification.
• The new step does not set or override env; it only reads and compares.
• build_ios_flask_release was removed as a thin wrapper that only called build_ios_flask_prod; callers can use the prod workflow directly.

Reason for the change: Prepare for Bitrise deprecation by having build config in one place and validating parity between Bitrise and builds.yml before any migration.

Improvement: Clear, version-controlled build config and optional verification in CI without changing current Bitrise behavior or outcomes.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: Build config and Bitrise verification

Scenario: CI runs existing Bitrise workflows unchanged
Given a branch with this PR merged
When a Bitrise build runs (e2e, Android/iOS prod, etc.)
Then all existing steps run as before
And Phase 1.5 verification runs optionally (skippable, non-blocking)
And the build outcome is unchanged

Screenshots/Recordings

N/A – CI/config only; no UI changes.
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.

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.