[CI] Unified label dispatcher and PR gate with clean concurrency control
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Start by reading the existing caller workflows (CI.yml, Documentation.yml, Breakage.yml, and ReleaseGate.yml), guard.yml, and the release procedure in ct-agents/recipes/release.md. Then map the existing label triggers and reusable workflow interfaces before designing a central dispatcher. Done means the gate handles closed PRs and superseded label events as specified, and is validated in OptimalControlProblems.jl.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Context
The release recipe of ct-agents (recipes/release.md, step 3.6) explicitly documents a procedure to avoid concurrency issues when applying multiple labels:
Push; open the PR; close it; add all the labels; reopen it.
Why: The label-gated callers react to
labeled,synchronizeandreopened. Labels added one by one on an open PR fire onelabeledevent each, and workflows concerned by several labels (e.g. CI, documentation, preview) start more than one run on the same commit. Reopening the PR fires a singlereopenedevent, reading the full label set at once: exactly one run per workflow.Why it is safe: Currently, a
labeledevent triggers the workflow, butguard.ymlin CTActions checks:- name: A pull request that is not open if: github.event_name == 'pull_request' && github.event.pull_request.state != 'open'and exits in a few seconds. Only the reopening runs the full tests.
However, on standard development PRs (outside release procedures), agents and developers frequently add labels directly on open PRs (or via API / UI one by one), re-triggering this exact avalanche of concurrent redundant runs.
Problem
- Multiple triggers on open PRs: Adding N labels on an open PR still spawns N runs per workflow simultaneously.
- Scattered guards: Today, each caller (
CI.yml,Documentation.yml,Breakage.yml,ReleaseGate.yml) has its own trigger/guard mechanism and its own concurrency management (or lack thereof), leading to race conditions where older runs cancel newer ones or runs pile up on the same commit. - The close/label/reopen dance: While this pattern works, it is an operational workaround for GitHub Actions' lack of built-in event debouncing on PR labeling.
Proposal
Design a Unified Label Dispatcher / Central Gate in CTActions:
- Strict PR state check (respecting the convention):
- The dispatcher's very first step verifies:
if: github.event_name == 'pull_request' && github.event.pull_request.state != 'open' - When the PR is closed, the dispatcher immediately exits with success/skip in < 2 seconds, completely guaranteeing that the "close PR -> set multiple labels -> reopen PR" pattern of
ct-agents/recipes/release.mdremains 100% valid, safe, and silent.
- The dispatcher's very first step verifies:
- Debounce & cancel superseded runs via concurrency:
- For open PRs where labels are added one by one, use a unified concurrency group on the dispatcher:
concurrency: group: pr-dispatch-${{ github.event.pull_request.number }} cancel-in-progress: true - If a developer/agent adds
run ci github-runner, and 2 seconds latertest ModelingToolkit backend, the first dispatch run is immediately cancelled before it spawns the heavy downstream runners.
- For open PRs where labels are added one by one, use a unified concurrency group on the dispatcher:
- Single Dispatcher calling reusable workflows:
- The gate evaluates the full label set against a registry of known labels (
run ci ...,run documentation,run breakage,test <scope> ...), computes the required actions, and calls the appropriate reusable workflows (ci.yml,documentation.yml,breakage.yml). - Replaces redundant per-workflow listening loops across repositories.
- The gate evaluates the full label set against a registry of known labels (
Done when
- A central label dispatcher / gate workflow is implemented in
CTActions. - Closed PRs immediately terminate at step 1 without scheduling any jobs (preserving
recipes/release.mdcompatibility). - Concurrency group cancels superseded dispatch runs when multiple labels are added consecutively on an open PR.
- Validated on a pilot repository (
OptimalControlProblems.jl).
- Lingua principale
- Julia
- Stelle
- 1
- Fork
- 0
- Merge medio
- 3h 6m
- PR unite (30g)
- 45
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di control-toolbox/CTActions
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
control-toolbox/CTActions#139 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
control-toolbox/CTActions#150 ·
I maintainer di solito rispondono entro 1 giorno
-
Label-triggered workflows: accumulate runs instead of hiding/cancelling them (label → workflow_dispatch)Forse già presa @ocots l’ha presa oggi. Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
control-toolbox/CTActions#149 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
control-toolbox/CTActions#133 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
control-toolbox/CTActions#132 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di control-toolbox/CTActions
Issue simili
-
documentation priority: high
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
epiforecasts/BVDOutbreakSize#1260 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
TuringLang/Turing.jl#2917 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100