Fix the CI

[lukaszgryglicki]

Signed-off-by: Lukasz Gryglicki lgryglicki@cncf.io

Assisted by OpenAI

Assisted by GitHub Copilot

Assisted by Claude

[coderabbitai]

Walkthrough

The deploy-dev workflow's concurrency configuration was updated to prevent automatic cancellation of in-progress deployment runs. When new deployments are triggered, existing runs in the deploy-dev group will now complete without interruption instead of being canceled.

Changes

Deploy Workflow Concurrency

Layer / File(s)	Summary
Concurrency configuration update .github/workflows/deploy-dev.yml	The cancel-in-progress setting for the deploy-dev concurrency group changed from true to false, allowing overlapping deployment workflows to proceed without cancellation.

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly Related PRs

• linuxfoundation/easycla#5069: Updates the same cancel-in-progress concurrency setting in the deploy workflow but with the opposite boolean value.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title "Fix the CI" is vague and does not specify what aspect of CI is being fixed or what the actual change is.	Use a more specific title that describes the actual change, such as "Prevent deploy workflow from canceling in-progress runs" to clarify what CI issue is being addressed.
Description check	❓ Inconclusive	The description contains only sign-off and attribution information with no explanation of the actual changes or their purpose.	Add details explaining what the CI issue was and how this change fixes it, such as describing the workflow concurrency configuration change and its impact.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch unicron-fix-ci-double-trigger

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Updates the DEV deployment GitHub Actions workflow concurrency behavior to stop cancelling in-progress runs, which can help stabilize deployments/tests that rely on a complete deploy run finishing.

Changes:

• Set concurrency.cancel-in-progress to false for the DEV deploy workflow so new runs queue instead of cancelling the active run.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with 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.

Inline comments:
In @.github/workflows/deploy-dev.yml:
- Around line 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.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: eb08e5ca-d5d9-48ee-8892-c744d99569ba

📥 Commits

Reviewing files that changed from the base of the PR and between 3f3ecbd and b0bb85d.

📒 Files selected for processing (1)

• .github/workflows/deploy-dev.yml

[coderabbitai]

⚠️ 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:

• 1: https://raw.githubusercontent.com/github/docs/refs/heads/main/content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md
• 2: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
• 3: https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency
• 4: Clarify concurrency cancel-in-progress behaviour github/docs#30647

---

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.