feat: OTA update exp workflow

[weitingsun]

Description

New OTA updates workflow:

Changelog

CHANGELOG entry: Added OTA updates workflow

Related issues

Fixes: 21215

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

I was testing it with on pushing my branch. It was working from checking fingerprints to deploying EAS updates.
I haven't tested the part where we input PR number and branch name but I hardcoded these before so they should work with inputs as well. This can only be tested when this PR is merged into main.

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.

---

Note

Adds a GitHub Actions workflow to publish Expo EAS OTA updates gated by fingerprint comparison and team approval.

• CI / GitHub Actions:
  • New workflow /.github/workflows/push-eas-update.yml for Expo EAS OTA updates:
    • fingerprint-comparison: checks out PR and base branch, installs deps, generates Expo fingerprints, compares, and records summary.
    • approval: requires mobile-platform team approval for OTA when fingerprints match.
    • push-update: verifies eas script and required secrets/vars, prepares signing key, and publishes eas update to the configured EXPO_CHANNEL, adding success/failure summaries.
    • fingerprint-mismatch: fails the run if fingerprints differ (native changes detected).

^{Written by Cursor Bugbot for commit bf2fc08. This will update automatically on new commits. 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.

[asalsys]

Approving to test the workflow:

https://github.com/MetaMask/metamask-mobile/actions/workflows/push-eas-update.yml

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 95%

click to see 🤖 AI reasoning details

This change introduces a new GitHub Actions workflow file (.github/workflows/push-eas-update.yml) for publishing OTA (Over-The-Air) updates via Expo EAS.

Key findings:

1. This is purely CI/CD infrastructure - a new deployment workflow
2. No application code is modified
3. No E2E test infrastructure is affected
4. The workflow provides a mechanism to publish OTA updates by:
   • Comparing Expo fingerprints to detect native changes
   • Requiring team approval
   • Publishing EAS updates when conditions are met

The OTA updates functionality already exists in the application (confirmed by finding useOTAUpdates hook in app/components/hooks/useOTAUpdates.ts), so this workflow is just adding a new distribution mechanism, not changing app behavior.

Since this is a workflow for deployment/release processes and doesn't modify any runtime application code, E2E test infrastructure, or critical paths, no E2E tests are needed to validate this change.

The workflow itself should be tested through its own execution (running the workflow), not through application E2E tests.

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]

I may have missed it - Are there docs on how the workflow is used especially for release engineers?