chore: restrict commit message for running release builds

[sethkfman]

Description

Summary

Add validation to ensure release builds only proceed with correct commit message format.

Changes

• Added new workflow step: check_release_commit_message that validates commit messages contain the expected pattern [skip ci] Bump version number to
• Integrated validation: Added the check to both Android and iOS release workflows (build_android_rc_and_upload_sourcemaps and build_ios_rc_and_upload_sourcemaps)
• Fail-safe behavior: If commit message doesn't match expected pattern, the workflow fails and instructs the user to run a version bump command requiring a release build to be a new number.

Technical Details

• The validation step uses BITRISE_GIT_MESSAGE environment variable to check the commit message
• Uses grep -q to perform pattern matching without output
• Implements proper error handling with set -e and set -o pipefail
• Includes debug logging with set -x

Purpose

This change helps prevent accidental release builds by ensuring only commits with the proper version bump message format trigger the release workflow, improving CI/CD reliability and preventing unintended releases.

Files Modified

• bitrise.yml - Added commit message validation workflow step

---

Commit: 797ced05a2 - added check to fail release build if it doesn't contain the correct commit number

Changelog

CHANGELOG entry:

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

Testing

• Verify the workflow step executes correctly
• Test with both valid and invalid commit messages
• Confirm release workflows still function as expected

Expected PASS

• iOS
• Android

Expected FAIL

• iOS
• Android

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

Enforces a commit-message check before release builds and bumps all build numbers to 2649 across CI and iOS project configs.

• CI/CD:
  • Add check_release_commit_message workflow to validate BITRISE_GIT_MESSAGE matches [skip ci] Bump version number to and fail with guidance otherwise.
  • Invoke this check in build_android_release_and_upload_sourcemaps and build_ios_release_and_upload_sourcemaps.
• Versioning:
  • Bump VERSION_NUMBER and FLASK_VERSION_NUMBER in bitrise.yml to 2649.
  • Update iOS CURRENT_PROJECT_VERSION to 2649 across MetaMask, MetaMask-Flask, and MetaMask-QA configurations in ios/MetaMask.xcodeproj/project.pbxproj.

^{Written by Cursor Bugbot for commit 2bbba2d. 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.

[cursor]

Bug: Multiline YAML Pattern Causes Commit Message Validation Failure

The grep pattern for checking the commit message is split across two lines in the YAML, causing it to search for a literal newline character. This prevents the workflow from correctly identifying valid release commit messages.

 

[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