-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
Coming from #7255 ...
Problem
There exists a race condition when the CP Staging is applied to a pull request after it's merged. Both of the following are possible:
- When the merged pull request is fetched here, it already has the
CP Staginglabel, and is deployed to staging. - When the merged pull request is fetched in the location listed above, it does not have the
CP Staginglabel, and is not deployed to staging.
In both scenarios, a comment that looks like this will be left on the pull request:
Why this is important
In the second scenario, this is confusing because the expected behavior/whether or not the pull request was CP'd to staging is unclear.
Solution
Update the warnCPLabel.yml workflow to tailor its comment based on whether or not the CP Staging label was applied to the pull request when it was already merged.
- If the pull request not yet merged, keep the same comment.
- If the pull request is already merged, use the following comment:
-
Find the
preDeploy.ymlworkflow run for the pull request. -
List jobs for that workflow run and find the
skipDeployjob. -
If the conclusion of that job is not resolved, poll the API until it is resolved.
-
If the conclusion is
successor something else, use the following comment:
⚠️ Heads up!⚠️ Since theCP Staginglabel was applied after this PR was merged, it was not CP'd to staging. If you need it to be deployed to staging, tag a member of @Expensify/mobile-deployers to CP it manually.
-
If the conclusion is
skipped, use the following comment:
⚠️ Heads up!⚠️ TheCP Staginglabel was applied after the PR was merged. This leads to unpredictable behavior. In this case this PR will be deployed to staging, but to guarantee this in the future be sure to apply theCP Stagingbefore merging the pull request.
-
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~0131b521e37dc4e067
- Upwork Job ID: 1593348486831874048
