[ci-coach] ci: add concurrency group to release workflow

[github-actions]

Summary

Add a concurrency group to the release workflow to serialize release-please executions and prevent wasted parallel compute when multiple commits land on main in quick succession.

Optimizations

1. Serialize release-please runs with concurrency group

Type: Conditional Execution / Resource
Impact: Eliminates duplicate parallel release-please runs; minor compute savings per batch push
Risk: Low

Changes:

• Added concurrency.group keyed on $\{\{ github.workflow }}-$\{\{ github.ref }} to the root of release.yml
• Set cancel-in-progress: false to queue (not cancel) concurrent runs, so every commit is evaluated by release-please

Rationale: Unlike ci.yml (which already has concurrency cancellation for faster feedback), the release workflow should never skip a commit — it must see every push to maintain an accurate changelog and version manifest. With cancel-in-progress: false, a second run waits for the first to finish, then runs itself. This prevents two release-please jobs from simultaneously updating the manifest file, which can cause race-condition conflicts in the release PR.

Detailed Analysis

Observed gap: ci.yml has had concurrency since PR #178 (Mar 2), but release.yml never received the same treatment.

When does this matter? Dependabot frequently merges multiple bumps in the same day (e.g., #191 and #194 merged on the same day, Mar 9). Each merge triggers a separate release.yml run. Without a concurrency group, both runs execute simultaneously, both reading and potentially writing the release-please manifest at the same time.

Why cancel-in-progress: false? CI workflows benefit from cancellation (old runs become irrelevant when new commits arrive). Release workflows don't — skipping a commit means that commit's changelog entry and version bump could be missed. Queuing ensures correctness.

Before: Two pushes within seconds → two simultaneous release-please jobs
After: Two pushes within seconds → first job runs, second queues and runs after

Expected Impact

• Compute Savings: Eliminates occasional duplicate release-please runs (~1–2 min each)
• Correctness: Prevents potential manifest conflicts under rapid push scenarios
• Risk Level: Low — cancel-in-progress: false means no runs are dropped; behaviour is additive

Testing Recommendations

• Review workflow YAML syntax
• Observe next batch of dependabot merges to confirm queuing behavior
• Confirm release-please PR is created/updated correctly after multiple rapid pushes

Generated by CI Optimization Coach · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/ci-coach.md@b466f28f0f65b68d6f2b10b15b44f51d787b93be

• expires on Mar 15, 2026, 1:16 PM UTC

---

Note

This was originally intended as a pull request, but the git push operation failed.

Workflow Run: View run details and download patch artifact

The patch file is available in the agent-artifacts artifact in the workflow run linked above.

To create a pull request with the changes:

# Download the artifact from the workflow run
gh run download 23052290962 -n agent-artifacts -D /tmp/agent-artifacts-23052290962

# Create a new branch
git checkout -b ci/add-release-concurrency-bbfb891d8ee4be60

# Apply the patch (--3way handles cross-repo patches where files may already exist)
git am --3way /tmp/agent-artifacts-23052290962/aw-ci-add-release-concurrency.patch

# Push the branch to origin
git push origin ci/add-release-concurrency-bbfb891d8ee4be60

# Create the pull request
gh pr create --title '[ci-coach] ci: add concurrency group to release workflow' --base main --head ci/add-release-concurrency-bbfb891d8ee4be60 --repo askpt/code-metrics

Show patch (38 lines)

From 30dd56f8c770f75feb0a03b4473173764934950b Mon Sep 17 00:00:00 2001
From: "github-actions[bot]" <github-actions@github.com>
Date: Fri, 13 Mar 2026 13:14:36 +0000
Subject: [PATCH] ci: add concurrency group to release workflow

Prevent parallel release-please executions when multiple commits land
on main in quick succession (e.g., batched dependabot updates).

Using cancel-in-progress: false to queue rather than cancel, ensuring
every commit is considered by release-please and no changelog entries
are silently dropped.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .github/workflows/release.yml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index f27dc00..58f0e31 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -5,6 +5,12 @@ on:
     branches:
       - main
 
+# Serialize release runs so rapid pushes to main don't create parallel
+# release-please executions that could conflict over manifest state.
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: false
+
 jobs:
   release-please:
     timeout-minutes: 5
-- 
2.53.0

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the detailed analysis from CI Coach! This is a solid, low-risk improvement. I've implemented the patch and created a draft PR applying the concurrency group to release.yml.

The change uses cancel-in-progress: false to queue (not cancel) concurrent runs — which is the right call for a release workflow where every commit must be evaluated.

I'll link the PR number here once it's visible in the repository.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@b466f28f0f65b68d6f2b10b15b44f51d787b93be

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.