throwaway PR: test build number bump in build time only - #34515
throwaway PR: test build number bump in build time only#34515joaoloureirop wants to merge 8 commits into
Conversation
…them Stop pushing [skip ci] Bump version number commits to release branches by removing commit-build-version.yml and passing generated build numbers into build.yml for RC, production, and auto RC workflows. Release cut no longer allocates a new build number via create-release-pr; it reads the current value for github-tools validation only. Fixes MCWP-527
Keep iOS and Android on the same commit after removing bump commits, so cherry-picks mid-run cannot diverge platforms under one build number. Co-authored-by: Cursor <cursoragent@cursor.com>
|
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. |
PR template — items to address before "Ready for review"Blocking — these items fail the workflow until fixed:
Warnings — informational, address before merging:
See docs/readme/ready-for-review.md for the full Definition of Ready for Review. |
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsE2E Test Selection:
None of these changes affect:
The PR is a pure CI/CD refactoring that changes how build numbers are applied (locally at build time vs. committed to the branch). This has zero impact on E2E test scenarios or performance benchmarks. No E2E tags or performance tags should be selected. Performance Test Selection: |
|
🚀 RC Builds Ready for Testing
More Info
🛡️ Build Environment
API URLs & Details
Build Flags:
🍒 What's in this RCCherry-picks (2 commits)
Changelog (859 commits from main at RC cut)
AI Test Plan
Executive SummaryRelease Focus: CI/CD pipeline restructuring to move build number bumping from a dedicated workflow into build-time execution, consolidating release automation scripts. Key Changes:
Critical Areas: Release PR creation and version number accuracy in app builds, Build artifact integrity and correct version stamping on iOS and Android, OTA (over-the-air) update build pipeline correctness, Core wallet operations to confirm no regressions from build pipeline changes Overall Risk: MEDIUM Recommendation: Conditional go — the app's functional code is unchanged, but the restructured build pipeline introduces risk that shipped binaries may carry incorrect version numbers or build metadata. QA should verify that the installed build reports the correct version string, build number, and that release artifacts are properly stamped before approving for production release. Release Scenarios (5)High Risk Scenarios (3)1. Build Version & App MetadataRisk Level: HIGH Why This Matters: The commit-build-version.yml workflow (64 lines) was entirely deleted and its responsibilities absorbed into create-release-pr.yml and build-time logic. If the migration is incomplete or the new workflow fires at the wrong stage, the build number may not be committed, may be duplicated, or may be stamped with an incorrect value. This is the core risk of this PR and directly affects what version users see and what stores accept. Preconditions:
Test Steps:
Expected Outcomes:
2. OTA Update DeliveryRisk Level: HIGH Why This Matters: auto-rc-ota-build-core.yml received new additions (+6 lines) as part of this restructuring. OTA builds have a separate pipeline from native builds, and any misconfiguration in how the build number or bundle version is passed to the OTA pipeline could result in users receiving an update that the app rejects, loops on, or that carries wrong metadata. OTA failures are particularly severe as they can break existing installs. Preconditions:
Test Steps:
Expected Outcomes:
3. Release PR Automation & Version ConsistencyRisk Level: HIGH Why This Matters: create-release-pr.yml had 26 lines added and 6 removed, absorbing logic from the deleted commit-build-version.yml. The script create-release-pr.sh was also simplified. If the version commit logic was not fully migrated or fires at the wrong workflow step, the release PR could be created with wrong version numbers, which would propagate to all shipped binaries. The CODEOWNERS removal also reduces oversight on critical release files. Preconditions:
Test Steps:
Expected Outcomes:
Medium Risk Scenarios (2)1. Wallet Operations - Core RegressionRisk Level: MEDIUM Why This Matters: While this PR only modifies CI/CD workflows and scripts, a misconfigured build pipeline can inadvertently include wrong JavaScript bundles, incorrect environment variables, or mismatched native/JS versions. Core wallet regression testing on the actual shipped binary confirms the build artifacts are internally consistent and functional, not just correctly versioned. Preconditions:
Test Steps:
Expected Outcomes:
2. RC Build Pipeline - iOS and Android Artifact IntegrityRisk Level: MEDIUM Why This Matters: build-rc-auto.yml had 13 lines added and 20 removed, and runway-rc-builds.yml had 9 added and 16 removed. These are significant structural changes to the pipelines that produce the actual RC binaries. Reduced line counts suggest consolidation, but if any required build steps were accidentally removed along with the refactoring, the resulting artifacts could be misconfigured, unsigned, or built against wrong environments. Preconditions:
Test Steps:
Expected Outcomes:
Excluded Features - Feature Flags Disabled (99)The following features are disabled via feature flags and should NOT be tested:
Generated by AI Test Plan Analyzer (claude-sonnet-4-6) at 2026-08-07T23:57:50.797Z AI generated test plan (JSON): Available as artifact |



Description
Changelog
CHANGELOG entry:
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Performance checks (if applicable)
trace()for usage andaddTokenfor an exampleFor performance guidelines and tooling, see the Performance Guide.
Pre-merge reviewer checklist