[AUTO-INF-5] Add workflow-level concurrency controls to prevent redundant parallel CI runs #10231

New issue

Open

opened 2026-04-17 09:09:38 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-17 09:09:38 +00:00

Owner

Summary

All four CI workflow files (ci.yml, master.yml, release.yml, nightly-quality.yml) lack a concurrency: block at the workflow level. Without concurrency controls, multiple pushes or PR updates in quick succession can trigger multiple simultaneous workflow runs for the same branch, wasting runner resources and producing confusing interleaved results.

Problem

None of the following workflows define concurrency: at the top level:

.forgejo/workflows/ci.yml — triggers on push and pull_request
.forgejo/workflows/master.yml — triggers on push
.forgejo/workflows/release.yml — triggers on tag push
.forgejo/workflows/nightly-quality.yml — triggers on schedule and workflow_dispatch

For PR-based workflows (ci.yml), this means that every new commit pushed to a PR branch starts a fresh full CI run while the previous run is still in progress, consuming double (or more) runner capacity for work that will be discarded.

Proposed Fix

Add a concurrency: block at the workflow level of each affected file. For example, in ci.yml:

concurrency:
  group: ${{ forgejo.workflow }}-${{ forgejo.ref }}
  cancel-in-progress: true

For release.yml, cancel-in-progress should be false to avoid cancelling an in-flight release publish.

Impact

Eliminates wasted runner capacity from redundant parallel runs
Reduces queue wait times for other PRs
Prevents confusing interleaved log output from concurrent runs on the same branch

Duplicate Check

The following existing issues were reviewed before filing this issue:

#10197: Add job-level timeout-minutes to all CI jobs in ci.yml — about timeouts, not concurrency
#9953: Nightly quality workflow omits integration_tests and e2e_tests — about missing test steps
#9951: Fix rentention-days typo in master.yml benchmark jobs — about a typo
#9943: Add job-level timeout-minutes to all CI jobs in ci.yml — about timeouts
#9890: Improve Docker caching, template DB reuse, and release SBOMs — about caching/SBOMs
#9778: Stabilize Behave/Robot test layers to cut CI flake — about test stability
#9697: Harden CI quality gates — about coverage parity and nightly enforcement
#9128: CI Pipeline Design: Guard integration/e2e jobs when LLM secrets unavailable — about secret-gating
#9767: Harden CI workflow reliability — about runner setup and secret-dependent jobs
#10067: Add missing job dependencies in CI pipeline — about job needs: dependencies
#10068: Add timeout configurations and path filters to CI workflows — about timeouts and path filters

None of the above issues address workflow-level concurrency controls. This is a new, distinct finding.

Automated by CleverAgents Bot
Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor

## Summary All four CI workflow files (`ci.yml`, `master.yml`, `release.yml`, `nightly-quality.yml`) lack a `concurrency:` block at the workflow level. Without concurrency controls, multiple pushes or PR updates in quick succession can trigger multiple simultaneous workflow runs for the same branch, wasting runner resources and producing confusing interleaved results. ## Problem None of the following workflows define `concurrency:` at the top level: - `.forgejo/workflows/ci.yml` — triggers on `push` and `pull_request` - `.forgejo/workflows/master.yml` — triggers on `push` - `.forgejo/workflows/release.yml` — triggers on tag push - `.forgejo/workflows/nightly-quality.yml` — triggers on schedule and `workflow_dispatch` For PR-based workflows (`ci.yml`), this means that every new commit pushed to a PR branch starts a fresh full CI run while the previous run is still in progress, consuming double (or more) runner capacity for work that will be discarded. ## Proposed Fix Add a `concurrency:` block at the workflow level of each affected file. For example, in `ci.yml`: ```yaml concurrency: group: ${{ forgejo.workflow }}-${{ forgejo.ref }} cancel-in-progress: true ``` For `release.yml`, `cancel-in-progress` should be `false` to avoid cancelling an in-flight release publish. ## Impact - Eliminates wasted runner capacity from redundant parallel runs - Reduces queue wait times for other PRs - Prevents confusing interleaved log output from concurrent runs on the same branch ### Duplicate Check The following existing issues were reviewed before filing this issue: - #10197: Add job-level timeout-minutes to all CI jobs in ci.yml — about timeouts, not concurrency - #9953: Nightly quality workflow omits integration_tests and e2e_tests — about missing test steps - #9951: Fix rentention-days typo in master.yml benchmark jobs — about a typo - #9943: Add job-level timeout-minutes to all CI jobs in ci.yml — about timeouts - #9890: Improve Docker caching, template DB reuse, and release SBOMs — about caching/SBOMs - #9778: Stabilize Behave/Robot test layers to cut CI flake — about test stability - #9697: Harden CI quality gates — about coverage parity and nightly enforcement - #9128: CI Pipeline Design: Guard integration/e2e jobs when LLM secrets unavailable — about secret-gating - #9767: Harden CI workflow reliability — about runner setup and secret-dependent jobs - #10067: Add missing job dependencies in CI pipeline — about job `needs:` dependencies - #10068: Add timeout configurations and path filters to CI workflows — about timeouts and path filters **None of the above issues address workflow-level concurrency controls.** This is a new, distinct finding. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor

HAL9000 referenced this issue

2026-04-17 11:22:32 +00:00

[AUTO-INF-POOL] Status: Test Infrastructure Pool (Cycle 4) #10206