Skip to content

[No QA] Require the staging Cloudflare Worker deploy and verify staging there - #104394

Merged
justinpersaud merged 2 commits into
mainfrom
jpersaud-require-staging-worker-deploy
Oct 19, 2026
Merged

justinpersaud merged 2 commits into
mainfrom
jpersaud-require-staging-worker-deploy

Conversation

@justinpersaud

Copy link
Copy Markdown
Contributor

Explanation of Change

Prepares the staging deploy for staging.new.expensify.com being served by the staging Cloudflare Worker instead of S3. The route switch itself happens later in the Cloudflare dashboard; this PR works before and after it.

  • The staging Worker deploy is now required. It moves out of the optional matrix job into webDeployStagingWorker, which runs after the S3 upload and has no continue-on-error. If the deploy fails, the staging deploy fails instead of silently leaving the old build live.
  • Staging is verified by that job. It runs verifyDeploy.sh against WEB_STAGING_HOST. The S3 job now only verifies production: after the switch, its check of the staging host would race the Worker deploy. Until the switch, the Worker job's check still reads the S3 copy, which is already in place because the job runs after the S3 upload.
  • The staging Worker counts towards the web deploy result. checkDeploymentSuccess reports a staging web failure if the Worker deploy didn't succeed, and the failure and cancellation Slack jobs include it. Production is unchanged.
  • test-staging stays an optional trial (webDeployTestStaging, continue-on-error).

Fixed Issues

For https://github.com/Expensify/Expensify/issues/688126
PROPOSAL:

Tests

  1. Run actionlint on .github/workflows/deploy.yml and verify it reports nothing new compared with main.
  2. Check the WEB_RESULT logic in checkDeploymentSuccess for each case and verify: staging with S3 and Worker both succeeding is success; a failed Worker or failed S3 deploy is failure; a cancelled Worker deploy is cancelled; production ignores the skipped Worker job.
  3. After merging, on the next staging deploy, verify Deploy Web to the staging Cloudflare Worker runs after Deploy Web to S3, uploads to the previous builds bucket, deploys, and passes Verify deploy against staging.new.expensify.com.
  4. Verify Deploy Web to S3 skips Verify deploy on staging, and still runs it on the next production deploy.
  • Verify that no errors appear in the JS console

Offline tests

N/A. Deploy pipeline only.

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

No QA. Deploy pipeline only; how staging and production are served doesn't change.

  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • If new assets were added or existing ones were modified, I verified that:
    • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
    • The assets load correctly across all supported platforms.
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
    • I verified that all the inputs inside a form are aligned with each other.
    • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
  • If the PR adds or modifies the UI:
    • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
    • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
    • I verified all new/changed elements have meaningful accessible names and roles.
    • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
  • I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari

Once staging.new.expensify.com is routed to the staging Worker, the S3 job's version check would race the Worker deploy, and a failed Worker deploy would leave the old build live without failing the staging deploy. The staging Worker now deploys in its own job after the S3 upload, verifies the staging host, and counts towards the web deploy result. test-staging stays an optional trial job, and the S3 job only verifies production.
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 19, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-19T19:10:44.371384Z 69dad0a PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@melvin-bot
melvin-bot Bot requested review from deetergp and removed request for a team October 19, 2026 19:00
@melvin-bot

melvin-bot Bot commented Oct 19, 2026

Copy link
Copy Markdown

@deetergp Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@justinpersaud
justinpersaud merged commit b9039c7 into main Oct 19, 2026
28 of 29 checks passed
@justinpersaud
justinpersaud deleted the jpersaud-require-staging-worker-deploy branch October 19, 2026 20:02
@github-actions

Copy link
Copy Markdown
Contributor

🚧 justinpersaud has triggered a test Expensify/App build. You can view the workflow run here.

@OSBotify

Copy link
Copy Markdown
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.

OSBotify pushed a commit that referenced this pull request Oct 19, 2026
…rker-deploy

[No QA] Require the staging Cloudflare Worker deploy and verify staging there

(cherry picked from commit b9039c7)

(cherry-picked to staging by AndrewGable)
@OSBotify OSBotify added the CP Staging marks PRs that have been CP'd to staging label Oct 19, 2026
@OSBotify

Copy link
Copy Markdown
Contributor

🚀 Cherry-picked to staging by https://github.com/AndrewGable in version: 9.5.14-1 🚀

platform result
🕸 web 🕸 success ✅
🤖 android 🤖 failure ❌
🍎 iOS 🍎 success ✅

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

Labels

CP Staging marks PRs that have been CP'd to staging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants