Skip to content

Release/test runway rc ios workflow#27650

Open
weitingsun wants to merge 9 commits intomainfrom
release/test-runway-rc-ios-workflow
Open

Release/test runway rc ios workflow#27650
weitingsun wants to merge 9 commits intomainfrom
release/test-runway-rc-ios-workflow

Conversation

@weitingsun
Copy link
Contributor

@weitingsun weitingsun commented Mar 18, 2026

Description

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

Pre-merge author checklist

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
Medium risk because it adds a new release-branch GitHub Actions workflow that conditionally triggers OTA dispatches or RC builds, and it changes app version/build numbers across Android, iOS, Bitrise, and package.json, which can impact release pipelines if misconfigured.

Overview
Adds a new GitHub Actions workflow, runway_ios_rc_workflow.yml, for release/* branches that decides between triggering an iOS RC OTA update (by dispatching push-eas-update.yml) or running the reusable build.yml workflow when no OTA_VERSION bump is detected.

Updates release metadata across the repo: bumps app/constants/ota.ts OTA_VERSION, and changes the app semantic version/build numbers in package.json, Android build.gradle, iOS Xcode project settings, and Bitrise env vars to match the intended RC build/versioning.

Written by Cursor Bugbot for commit 93bd6ad. This will update automatically on new commits. Configure here.

@weitingsun weitingsun requested a review from a team as a code owner March 18, 2026 20:46
@github-actions
Copy link
Contributor

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.

@metamaskbot metamaskbot added the team-mobile-platform Mobile Platform team label Mar 18, 2026
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const ref = '${{ inputs.ref || github.ref_name }}'.replace(/^refs\/heads\//, '');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Script injection via unsanitized inputs.ref in shell and JS

High Severity

The workflow_dispatch inputs.ref value is directly interpolated via ${{ inputs.ref || github.ref_name }} into both a shell command (line 55) and a JavaScript string literal (line 118) without sanitization. A user with repo write access could supply a crafted ref value (e.g., containing '; malicious_code; ' for JS or "; malicious_command; echo " for shell) to achieve arbitrary code execution in the workflow runner context, which has access to secrets.GITHUB_TOKEN and can dispatch other workflows. The safe pattern is to pass these values via environment variables rather than inline ${{ }} expressions.

Additional Locations (1)
Fix in Cursor Fix in Web

@github-actions github-actions bot added risk-low Low testing needed · Low bug introduction risk and removed risk-low Low testing needed · Low bug introduction risk labels Mar 18, 2026
@github-actions github-actions bot added risk-low Low testing needed · Low bug introduction risk and removed risk-low Low testing needed · Low bug introduction risk labels Mar 18, 2026
@github-actions github-actions bot added risk-low Low testing needed · Low bug introduction risk and removed risk-low Low testing needed · Low bug introduction risk labels Mar 18, 2026
@github-actions
Copy link
Contributor

🔍 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:
Changes are limited to CI workflows, version bump/downgrade, OTA_VERSION update, and native build metadata. No runtime JS logic, controllers, UI, navigation, state management, or feature flows were modified. E2E coverage is not required for release automation changes.

Performance Test Selection:
No UI, rendering, controller, network, or initialization logic was changed. Performance characteristics remain unaffected.

View GitHub Actions results

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

Fix All in Cursor

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

run: |
if [[ -z "${{ needs.decide.outputs.pr_number }}" ]]; then
echo "::error::No PR found for this branch. OTA update requires a PR number."
echo "::error::If you ran the workflow manually (workflow_dispatch), select your release branch in the 'Use workflow from' dropdown (e.g. release/test-runway-rc-ios-workflow), not main."
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test branch name hardcoded in production error message

Low Severity

The error message on this line uses release/test-runway-rc-ios-workflow as the example branch name. This is the current test branch for this PR, not a realistic release branch name. If this workflow ships to production, the guidance would confuse users — a real example like release/7.71.0 would be appropriate.

Fix in Cursor Fix in Web

# Version from package.json (e.g. 7.70.0) → base ref for OTA workflow is always v{VERSION}
VERSION=$(node -p "require('./package.json').version")
RELEASE_TAG="v${VERSION}"
echo "base_ref=${RELEASE_TAG}" >> "$GITHUB_OUTPUT"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OTA trigger uses non-existent tag as base ref

Medium Severity

base_ref is unconditionally set to RELEASE_TAG (e.g. v7.69.0) on line 78, but when that tag doesn't exist, the OTA bump detection falls back to comparing against origin/main (lines 91–95). If a bump is detected via that fallback path, trigger-ota dispatches push-eas-update.yml with base_branch pointing to the non-existent tag. The downstream workflow will then fail at checkout because that ref doesn't resolve, producing a confusing error instead of a clear guard.

Additional Locations (1)
Fix in Cursor Fix in Web

@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

risk-low Low testing needed · Low bug introduction risk size-M team-mobile-platform Mobile Platform team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants