[HOLD for payment 2024-06-06] [$250] `preDeploy.yml` should not skip on default branch if another run is queued

[blimpich]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Issue reported by: @blimpich
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1715015588472179?thread_ts=1713554811.796439&cid=C01GTK53T8Q
cc: @rayane-djouah

Action Performed:

1. merge a PR into main
2. immediately merge another PR into main

Expected Result:

Both runs should run to completion

Actual Result:

The first run is skipped/cancelled.

Screenshots/Videos

Example of skipped job

Go to https://github.com/Expensify/App/actions/workflows/preDeploy.yml and you will find many examples of skipped jobs by just looking through the recent merges.

Further context:

This was caused by this PR. We don't want to revert this PR because it saves resources on builds for pull requests, we just don't want it to apply to when we're merging into main.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013f9368ae63177d49
• Upwork Job ID: 1788618186197295104
• Last Price Increase: 2024-05-09
• Automatic offers:
• rayane-djouah | Reviewer | 0
• badeggg | Contributor | 0

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @rayane-djouah (External)

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (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.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~013f9368ae63177d49

[melvin-bot]

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

[amgenene]

Proposal:
Please re-state the problem that we are trying to solve in this issue.
The problem we are trying to solve is that when multiple pull requests are merged into the main branch in quick succession, the workflow runs triggered by earlier merges are being canceled due to the cancel-in-progress: true flag in the workflow concurrency configuration.
What is the root cause of that problem?
The root cause of the problem is the cancel-in-progress: true setting, which is designed to cancel any currently running workflows or jobs with the same concurrency group when a new workflow run is triggered. This behavior is desirable for pull requests, where we want to save resources and avoid running redundant workflows or jobs when a new commit is pushed. However, for merges into the main branch, we want all workflow runs to complete without being canceled, even if another merge happens shortly after.
What changes do you think we should make in order to solve the problem?
To solve the problem, we can introduce conditional logic in the workflow files to apply the cancel-in-progress: true setting only for pull requests and not for merges to the main branch.
For the preDeploy.yml workflow file (or any other workflow file that handles merges to the main branch), we can set the cancel-in-progress setting to false
What alternative solutions did you explore? (Optional)
An alternative solution could be to introduce a delay or a manual trigger for workflow runs triggered by merges to the main branch. This would prevent the second workflow run from canceling the first one, but it might introduce additional complexity or manual intervention in the deployment process.