Review all project workflow and ensure they use `concurrency` whenever possible

[kenodegard]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

Summary

By nature of having many active repos within one organization, we need to be sensitive to how we utilize our GitHub actions resources. We need to review all projects and check to see if they use concurrency whenever possible to avoid unnecessary jobs.

Linked Issues & PRs

Repository inventory refreshed 2026-08-12. Scope is public, active, non-fork repositories in the conda organization. Archived repositories, private security response repositories, and the public conda/nsis-mirror fork are excluded.

Reviewed against each default branch on 2026-08-12. Checked entries need no follow-up. Repositories without workflows are marked not applicable. Unchecked entries have findings in the 2026-08-12 audit.

• conda/.github
• conda/actions
• conda/assets — no workflows
• conda/ceps
• conda/cla — no workflows
• conda/communications
• conda/conda — Add concurrency limits to benchmark tracking conda#16527
• conda/conda-benchmarks
• conda/conda-build — ci: add workflow concurrency limits conda-build#6088
• conda/conda-classic-solver — ci: add workflow concurrency limits conda-pycosat-solver#39
• conda/conda-content-trust
• conda/conda-docs
• conda/conda-dot-org — ci: add workflow concurrency limits conda-dot-org#426
• conda/conda-index — ci: add workflow concurrency limits conda-index#343
• conda/conda-launchers
• conda/conda-libmamba-solver — ci: add workflow concurrency limits conda-libmamba-solver#1021
• conda/conda-lock — ci: add workflow concurrency limits conda-lock#929
• conda/conda-lockfiles — ci: add workflow concurrency limits conda-lockfiles#167
• conda/conda-maintainers-team-planning — no workflows
• conda/conda-pack
• conda/conda-package-handling — Add workflow concurrency limits conda-package-handling#344
• conda/conda-package-streaming — Add workflow concurrency limits conda-package-streaming#194
• conda/conda-plugin-template
• conda/conda-prefix-replacement
• conda/conda-pypi — Add workflow concurrency limits conda-pypi#488
• conda/conda-rattler-solver
• conda/conda-recipe-manager — Add workflow concurrency limits conda-recipe-manager#548
• conda/conda-recipe-manager-test-data
• conda/conda-self
• conda/conda-spawn — Add workflow concurrency limits conda-spawn#66
• conda/conda-standalone
• conda/conda-verify
• conda/constructor
• conda/cookiecutter-conda-python
• conda/governance
• conda/grayskull — ci: add workflow concurrency limits grayskull#673
• conda/infrastructure
• conda/issue-tracker
• conda/menuinst
• conda/pycosat
• conda/rattler — chore(ci): add workflow concurrency limits rattler#2678
• conda/schemas

[jezdez]

Audit completed 2026-08-12

I reviewed the current default branch of every repository in scope. The 42 public, active, non-fork repositories contain 308 workflow files across 39 repositories. Three repositories have no workflows.

The static pass used the existing zizmor v1.29.0 auditor concurrency-limits check. I then reviewed the triggers and recent run history for every workflow without complete workflow-level coverage.

• 269 workflows have workflow-level concurrency
• 3 workflows have job-level concurrency only
• 36 workflows have no concurrency
• 23 workflows should add workflow-level concurrency
• 3 workflows need a partial concurrency fix
• 13 workflows reasonably need no concurrency change now

Add workflow-level concurrency

Use a PR or ref-aware group with cancellation enabled for these 16 CI workflows:

• conda/conda-build: .github/workflows/docs.yml
• conda/conda-dot-org: .github/workflows/lint.yml
• conda/conda-index: .github/workflows/sphinx.yml
• conda/conda-lock: .github/workflows/zizmor.yaml
• conda/conda-package-handling: .github/workflows/sphinx.yml, .github/workflows/tests.yml
• conda/conda-package-streaming: .github/workflows/sphinx.yml
• conda/conda-recipe-manager: .github/workflows/commit_checks.yaml, .github/workflows/integration_tests.yaml
• conda/grayskull: .github/workflows/codeql.yml, .github/workflows/sphinx.yml, .github/workflows/tests.yml
• conda/rattler: .github/workflows/enforce-sha.yml, .github/workflows/lint-pr.yml, .github/workflows/lint.yaml, .github/workflows/merge-gatekeeper.yml

The usual group is ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} with cancel-in-progress: true.

Use event-specific groups for these seven workflows:

• conda/conda: .github/workflows/benchmarks.yml. Group by the originating pull request or workflow_run.head_branch, then cancel superseded runs.
• conda/rattler: .github/workflows/vouch-check-pr.yml. Group by pull request or issue number, then cancel superseded runs.
• conda/conda-index, conda/conda-lockfiles, conda/conda-pypi, and conda/conda-spawn: .github/workflows/pypi.yml
• conda/conda-lock: .github/workflows/release.yaml

For the five mixed CI and release workflows, group by pull request, release tag, or ref. Cancel CI runs, but use cancel-in-progress: ${{ github.event_name != 'release' }} so a publication is not interrupted.

Improve partial coverage

• conda/conda-lock: .github/workflows/mkdocs.yml only serializes its single job. Promote the group to workflow level and enable cancellation of obsolete builds.
• conda/rattler: .github/workflows/docs.yaml correctly serializes three deployment jobs with cancel-in-progress: false, but its pull request build is unprotected. Add PR-aware job concurrency without changing deployment behavior.
• conda/rattler: .github/workflows/release-rust.yaml protects only release-plz-pr. Move that group to workflow level with cancel-in-progress: false so release-plz-release cannot overlap another run.

No concurrency change now

• Release-only runs do not supersede one another: conda/conda-pack/.github/workflows/publish.yml and conda/grayskull/.github/workflows/publish_pypi.yml.
• Reusable workflows should inherit the caller's policy: conda/governance/.github/workflows/_create-meeting-notes-pr.yml and _sync-meeting-notes-pr.yml.
• These scheduled or manual jobs are short and show no meaningful overlap: conda/ceps/.github/workflows/bump-lockfile.yml, conda/conda-dot-org/.github/workflows/cron-publish.yml, conda/governance/.github/workflows/bump-lockfile.yml, and conda/governance/.github/workflows/meeting-notes.yml.
• Fix, enable, or remove these before adding concurrency: conda/conda-lock/.github/workflows/update-lockfile.yaml and the alltime.yml, month.yml, recent.yml, and year.yml workflows in conda/issue-tracker. The lockfile workflow's last 10 runs failed. Two issue-tracker workflows are disabled, and the other two are consistently failing.

Existing definitions that need correction

conda/conda-classic-solver/.github/workflows/docs.yml and conda/conda-libmamba-solver/.github/workflows/docs.yml both use the constant group pages with cancel-in-progress: true. A run from one pull request can cancel an unrelated pull request or the main deployment. Use a PR or ref-aware group instead.

Priority

Start with one focused conda/rattler change. merge-gatekeeper.yml has 3,606 runs, recent completed runs averaged about 1,009 seconds, and overlapping runs for the same pull request were visible today. The next groups are conda/grayskull, the standard CI workflows, and the mixed PyPI workflows.

The centrally managed workflows were already corrected by #1344. conda/actions#451 tracks the downstream suppressions that can now be revisited.

I left 16 repositories unchecked for actionable follow-up. The other 26 are complete or need no concurrency change, including three with no workflows. This issue should remain open.

[jezdez]

Closing summary

The repository inventory was refreshed on 2026-08-12. The audit reviewed 308 workflow files across 39 repositories and identified 23 workflow-level additions, 3 partial fixes, and 2 unsafe constant-group corrections.

The resulting work was delivered through 15 linked pull requests affecting 28 workflow files. All 15 pull requests merged by 2026-08-19.

A post-merge check on 2026-08-20 found 1,100 runs across the changed workflows:

• 214 obsolete runs were canceled by the newly added cancel-in-progress: true groups
• 200 of those cancellations were in conda/rattler, confirming the audit's original priority
• one additional pending Rattler release run was replaced after serialization moved to workflow scope, without interrupting the active release run
• no publication or release event was canceled
• all 28 concurrency settings remain on their default branches, with no revert, corrective follow-up, or regression attributable to these changes

GitHub does not expose the counterfactual completion time or billed minutes for canceled work, so 214 superseded runs is the defensible measurement rather than an estimate of runner minutes saved.

conda/issue-tracker remains unchecked intentionally. Its month.yml and recent.yml workflows are disabled, while alltime.yml and year.yml are failing because their direct pushes to protected main are rejected with GH013. Those workflows should be repaired, replaced, or removed before concurrency is reconsidered, so they are outside the actionable concurrency work completed here.

The separate organization-wide runner-capacity request remains tracked in #1427. These changes reduce avoidable work, but do not establish that the organization's runner limits were increased or that the broader capacity problem is solved.

With the audit and its actionable implementation complete, this issue can now be closed.