[CI] Unified label dispatcher and PR gate with clean concurrency control

Chiusa
#144 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

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
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, julia, yaml
Ambito
ci-cd

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

enhancement

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, synchronize and reopened. Labels added one by one on an open PR fire one labeled event 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 single reopened event, reading the full label set at once: exactly one run per workflow.

Why it is safe: Currently, a labeled event triggers the workflow, but guard.yml in 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

  1. Multiple triggers on open PRs: Adding N labels on an open PR still spawns N runs per workflow simultaneously.
  2. 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.
  3. 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:

  1. 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.md remains 100% valid, safe, and silent.
  2. 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 later test ModelingToolkit backend, the first dispatch run is immediately cancelled before it spawns the heavy downstream runners.
  3. 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.

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.md compatibility).
  • 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

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di control-toolbox/CTActions

Tutte le issue di control-toolbox/CTActions

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.