Skip to content

Fix the CI #5084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lukaszgryglicki merged 1 commit into from
Jun 2, 2026
Merged

Fix the CI #5084

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/deploy-dev.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ env:

concurrency:
group: deploy-dev
cancel-in-progress: true
cancel-in-progress: false
Comment on lines 26 to +28

@coderabbitai coderabbitai Bot Jun 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

According to GitHub Actions documentation, when a pull request is merged into a branch, can both pushon the target branch andpull_request_targetwithtypes: [closed]trigger for the same merge, and how doesconcurrency.cancel-in-progress: false behave for two runs in the same static concurrency group?

💡 Result:

Yes—both can trigger for the same merge. When a pull request is merged, the PR’s pull_request (or pull_request_target) event with types: [closed] will fire, and the merge also creates a push event on the branch the PR was merged into (the target branch). GitHub’s events documentation explains that to run when a PR merges you use the pull_request closed type with a condition on merged == true (the same applies to pull_request_target’s corresponding closed type), and it also documents the separate push event trigger for workflows on branch updates.[1][2] About concurrency.cancel-in-progress: false for two runs in the same static concurrency group: only one run can be “running” at a time within a concurrency group, and when a new run is queued while another is in progress, the queued run becomes pending; any previously pending run in the same group is canceled and replaced by the newest queued run. Setting cancel-in-progress: false prevents canceling the currently running run, but it does not prevent cancellation of the pending/queued run(s) when newer runs arrive (with the default queue: single, there is at most one pending run at a time).[3][4] So, with two near-simultaneous events that both create workflow runs in the same concurrency group: 1) The first run starts (in-progress). 2) The second run is queued as pending. 3) If additional runs arrive before the first completes, earlier pending runs are canceled/replaced—but the first in-progress run is not canceled because cancel-in-progress: false.[3][4] If you need, share the exact YAML (including your concurrency.group expression and whether you set queue:), and I can map it precisely to your scenario.

Citations:

Dedup deploy triggers—concurrency serializes runs but won’t prevent duplicate redeploys

deploy-dev.yml can enqueue two workflow runs for the same merge (push to dev and pull_request_target closed). With concurrency.group: deploy-dev, those runs won’t execute concurrently (only one in-progress run per group); however, cancel-in-progress: false still lets the queued run(s) execute afterward, causing the dev environment to be redeployed multiple times sequentially. Consider deduping at the trigger/condition level (or include a per-merge key like the merged commit SHA in concurrency.group if you only want one deploy per merge).

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/deploy-dev.yml around lines 26 - 28, The workflow
currently allows duplicate sequential deploys because concurrency.group is
static ("deploy-dev") and cancel-in-progress is false; fix by either deduping
triggers (e.g., only run on push to dev or add a guard in the
pull_request_target closed job to require github.event.pull_request.merged ==
true and that the target branch is dev) or change concurrency to use a per-merge
key and cancel in-progress runs (e.g., set cancel-in-progress: true and make
concurrency.group dynamic like "deploy-dev-${{
github.event.pull_request.merge_commit_sha || github.sha }}" so only one deploy
per merge/commit proceeds). Ensure you update the concurrency.group and/or the
pull_request_target condition accordingly.


jobs:
build-deploy-dev:
Expand Down
Loading