[No QA] Make deploy workflow manually dispatchable#90249
Merged
Conversation
Add a workflow_dispatch trigger so deployers can manually re-trigger a staging or production deploy without needing a new push to the branch. When manually triggered, the workflow checks out the branch corresponding to the ENVIRONMENT input and derives all environment-specific behavior from a DEPLOY_ENV env var rather than github.ref. Also guard the isCherryPick script against the missing commits payload on non-push triggers, and add a DEPLOY_SHA output so all downstream jobs check out the correct commit. Update cherry-pick conflict PR descriptions to note that the PR should ideally be merged by a deployer; if not, the deploy will fail and must be manually re-triggered (not retried). Fixes #89934 Co-authored-by: Cursor <cursoragent@cursor.com>
The env context is not available in job-level if conditions or reusable workflow with inputs. Expose DEPLOY_ENV as a prep job output and use needs.prep.outputs.DEPLOY_ENV in those locations instead. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
workflow_dispatch payloads contain no commits array, so the previous fallback to [] always produced IS_CHERRY_PICK=false. For a manual redeploy of a cherry-pick to production this caused SHOULD_BUILD_NATIVE and cherryPickExtraVersionBump to be skipped incorrectly. When commits are absent, fetch the HEAD commit message via the GitHub API using the DEPLOY_SHA captured earlier in the same job. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
P2: Fix concurrency group so push and manual dispatch runs for the same environment share the same group key and cancel each other correctly. Previously push triggers used refs/heads/staging while dispatches used staging, so cancel-in-progress didn't apply across trigger types. P1: Pass DEPLOY_SHA as a REF input to createDeployChecklist.yml so its checkout always uses the staging branch HEAD rather than whatever ref dispatched the calling workflow. Add a REF input to that workflow's workflow_call trigger and use it in the checkout step. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
When a cherry-pick conflict-resolution PR is merged, GitHub creates a merge commit at HEAD. The cherry-picked commit carrying the "(cherry-picked to ... by ...)" marker sits under the merge, not at HEAD itself, so the previous single-commit API lookup always returned false for this case. For workflow_dispatch, detect merge commits (parents.length > 1) and use compareCommits between the first parent and HEAD to retrieve all merged-in commits, which includes the cherry-pick commit with the marker. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
If a deploy fails after the tag has already been created and pushed, a manual re-trigger would immediately abort in prep because `git tag <existing>` exits 128. Make tag creation idempotent: if the tag already exists at HEAD, skip creation; if it exists at a different commit, fail loudly to avoid deploying the wrong code. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
For push-triggered runs, fall back to github.sha (the exact commit that triggered the push) rather than github.ref (the branch name). Using the branch name risks checking out a newer commit if the branch advances between the webhook firing and the checkout step, which would tag and deploy the wrong code on a re-run. For workflow_dispatch, inputs.ENVIRONMENT is set, so it is used as the branch ref to check out the target environment's branch tip as intended. Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
|
Codex Review: Didn't find any major issues. 🎉 ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
roryabraham
changed the title
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
For workflow_dispatch, HEAD alone misses the cherry-pick marker in
two cases:
1. Linear push (Mobile-Expensify path): the marker is amended onto
the version-bump commit; a final unmarked submodule-update commit
is pushed on top, becoming HEAD.
2. Merge commit (conflict-resolution PR): the marker sits on an inner
commit, not on the merge commit at HEAD.
Replace the per-case merge-commit detection with a single approach that
covers both: list the most recent prior tag on the same branch
(staging or production) and use compareCommits(prevTag, HEAD).
compareCommits follows all parents, so it catches markers in inner
commits of both linear and merge-commit topologies.
Filter by tag suffix to avoid false positives from cherry-picks that
were part of a prior deploy on the same branch.
Co-authored-by: Cursor <cursoragent@cursor.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
actions/checkout uses fetch-depth=1 and fetch-tags=false, so a tag pushed by a prior run is absent from the local workspace. The previous logic tried git tag first: it would succeed locally, then git push would be rejected by the remote because the tag already exists there, and the idempotent recovery path was never reached. Fix: fetch the remote tag first. If it now exists locally, check whether it points to the expected HEAD SHA and skip or fail accordingly. Only create and push if the tag is truly absent from the remote. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
@codex review |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
A fixed page size of 20 isn't enough for production dispatches: if more than 20 staging tags have been created since the last production release, listTags returns only staging tags on the first page and prevTag is undefined, causing the code to fall back to HEAD only and miss the cherry-pick marker. Paginate with per_page=100 until a matching tag (same suffix) is found or all tags have been exhausted. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
dmkt9
reviewed
May 12, 2026
| # v6 | ||
| uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd | ||
| with: | ||
| ref: ${{ inputs.ENVIRONMENT || github.sha }} |
Contributor
There was a problem hiding this comment.
I cannot run this directly, but the changes look good to me.
Additionally, I have a question regarding the cherryPick.yml file, which mentions re-triggering a failed commit:
**Important:** This PR should ideally be merged by a member of the [mobile-deployers](https://github.com/orgs/Expensify/teams/mobile-deployers) team. If it is merged by someone who is not a deployer, the staging deploy triggered by the merge will fail and will need to be manually re-triggered (not just retried) via the [deploy workflow](https://github.com/${{ github.repository }}/actions/workflows/deploy.yml).
Since we are using inputs.ENVIRONMENT == staging/production here, a manual re-trigger might initiate the workflow with a more recent commit than the one that originally failed. This seems slightly inconsistent with the instructions in cherryPick.yml. Is this intentional? Please let me know if I am misunderstanding anything.
francoisl
reviewed
May 12, 2026
Co-authored-by: Francois Laithier <francois@expensify.com>
Contributor
Reviewer Checklist
Screenshots/VideosN/A |
francoisl
approved these changes
May 12, 2026
Contributor
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
82 tasks
Contributor
|
🚀 Deployed to staging by https://github.com/francoisl in version: 9.3.73-0 🚀
Bundle Size Analysis (Sentry): |
Contributor
|
🚀 Deployed to staging by https://github.com/francoisl in version: 9.3.73-0 🚀
Bundle Size Analysis (Sentry): |
Contributor
|
🚀 Deployed to production by https://github.com/Beamanator in version: 9.3.73-4 🚀
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation of Change
Adds a
workflow_dispatchtrigger todeploy.ymlso that deployers can manually re-trigger a staging or production deploy from the GitHub Actions UI without needing to push a new commit to the branch.The workflow accepts an
ENVIRONMENTinput (stagingorproduction). When dispatched manually, it checks out the branch corresponding to that environment and runs the deploy from that branch as normal.Also updates cherry-pick conflict PR descriptions to note that the PR should ideally be merged by a deployer; if merged by a non-deployer, the deploy will fail and must be manually re-triggered (not just retried).
Fixed Issues
$ #89934
Tests
None.
Offline tests
n/a
QA Steps
None.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop