[$250] Combine deploy.yml and platformDeploy.yml

[roryabraham]

Problem

We have started to adopt the practice of shipping checklists but skipping prod deploys when there's only a few blockers left caused by a PR we don't want to revert. This allows us to engage Applause in QA of new code on staging and to uncover and fix any other blockers lurking on main while we work on fixing the remaining known blockers on staging. As a result of this practice, we avoid building a huge backlog of un-QA'd PRs, we avoid scenarios where we have many blockers introduced to staging at once, which saves our team time (particularly for the deployer that week).
However, this practice results in broken prod deploy comments. If a checklist is shipped and the prod deploy for that checklist is skipped, then the PRs included in that checklist never receive "deployed to prod" comments, even after the next complete and successful prod deploy. This is a problem because it leads to confusion for our BZ process and makes it harder to track when payments are due to contributors.

The root cause for this problem with deploy comments in this edge case lies in getDeployPullRequestList. That action looks for the version of the last completed deploy for the given environment, and tries to enumerate all PRs between that version and the just-deployed version. It does not work in the edge case of a skipped prod deploy, because there's always a staging deploy with a matching version. When determining if a deploy matches the given environment, it looks at whether the release for that deploy is a prerelease (staging) or finalized (production). However, even if a prod deploy was skipped, that skipped deploy workflow was triggered by a finalized release. So our code mistakes the staging deploy with the same version code as the skipped prod deploy for a prod deploy.

Solution

First some background... Right now, we have two workflows involved in creating deploys.

1. First, deploy.yml is triggered when code is pushed to staging or production branches. This is the "root" event that puts a deploy in motion. deploy.yml just:
   1. Creates and pushes a tag for the version on that branch (staging)
   2. creates a release for that tag (staging)
   3. finalizes the release for that tag (production)
2. The event of creating or finalizing a release in turn triggers platformDeploy.yml, which builds the code for that release, puts it where it needs to go, and leaves deploy comments when it's done.

So to solve this problem of staging deploys being mistaken for prod deploys, we can actually combine these two workflows into a single workflow, which we'll call deploy.yml. It will:

1. Create and push a tag for the version on the branch that triggered it (staging)
2. Run the staging or prod deploy using the code on that branch
3. Once the actual deploy completes successfully on at least one platform:
   1. Leave deploy comments on all PRs since the last prerelease (staging) or finalized release (prod)
   2. Once the deploy completes successfully, create or finalize a release for that deploy

By waiting for an actual deploy to complete before creating a release, we never have to worry about releases being associated with cancelled deploys, or about them being falsely matched with a workflow different than the one that created or finalized them.
When looking for the last completed staging deploy, we simply look at the newest release (prerelease or finalized). When looking for the last completed prod deploy, we simply look at the latest finalized release.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019fe3122b194caa3c
• Upwork Job ID: 1830720256093569547
• Last Price Increase: 2024-09-02

Issue Owner

Current Issue Owner: @

[melvin-bot]

Triggered auto assignment to @sakluger (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[roryabraham]

auto-assigner is going to be confused here. I'll be the "C+" for this issue and @rayane-djouah will be the contributor. And we're skipping the proposal phase because we've already hashed out the solution in slack

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~019fe3122b194caa3c

[melvin-bot]

Current assignee @rayane-djouah is eligible for the External assigner, not assigning anyone new.

[roryabraham]

@rayane-djouah any update here?

[rayane-djouah]

PR in progress

[rayane-djouah]

@roryabraham PR ready for review

[rayane-djouah]

Here is the list of pull requests that resolve this issue:

• [No QA] Combine deploy.yml and platformDeploy.yml #48635
• [CP Staging] [No QA] Update artifacts names and add "Rename sourcemaps artifacts" step #48737
• [No QA] Fix finalizeRelease job #48792
• [No QA] Create a manual workflow for PRs deployment comments #48938
• [No QA] Fix finalizeReleaseJob, add --clobber option #49017
• [No QA] Fix post slack message workflow is being skipped #49143
• [No QA] Fix checkDeploymentSuccess job in deploy workflow #49432

[rayane-djouah]

No checklist is needed here since this is a Github Actions improvement

[rayane-djouah]

@roryabraham Is there anything left to do here?