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-classic-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.