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 Staging label, and is deployed to staging.
- When the merged pull request is fetched in the location listed above, it does not have the
CP Staging label, 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.yml workflow run for the pull request.
-
List jobs for that workflow run and find the skipDeploy job.
-
If the conclusion of that job is not resolved, poll the API until it is resolved.
-
If the conclusion is success or something else, use the following comment:
⚠️ Heads up! ⚠️ Since the CP Staging label 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! ⚠️ The CP Staging label 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 the CP Staging before merging the pull request.
Upwork Automation - Do Not Edit
Coming from #7255 ...
Problem
There exists a race condition when the
CP Stagingis applied to a pull request after it's merged. Both of the following are possible:CP Staginglabel, and is deployed to staging.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 Staginglabel was applied to the pull request when it was already merged.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:CP 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:CP 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