[mkczarkowski]

Co

ci.yml dostaje concurrency na poziomie workflow:

• pull_request: grupa ci-pr-<numer> z cancel-in-progress: true. Nowy push do PR anuluje trwający run.
• push i pozostałe eventy: grupa ci-<run_id>, czyli unikalna, i cancel-in-progress: false. Run na master nigdy nie zostanie anulowany ani porzucony jako oczekujący, więc release, który niesie, zawsze się wykona.

Po co

Pierwszy run CI każdego PR pada z założenia: version-bootstrap czeka, aż Prepare CLI version doda commit chore(release): prepare vX.Y.Z. W ostatnich 30 dniach mediana to 2 runy CI na PR, a w 21 z 37 PR-ów pierwszy był czerwony. Po tej zmianie taki run zostaje anulowany (szary) w chwili, gdy przychodzi commit bumpa, zamiast kończyć się czerwienią po ~1,8 min. Działa to też przy każdym szybkim drugim pushu.

Bezpieczeństwo (warunki vg-orch)

• Brak skutków ubocznych w anulowanym jobie. W ci.yml jedyny krok związany z wersją to prepare-version.mjs --bootstrap w version-bootstrap. Na tej ścieżce są tylko GET-y do API, git fetch, zapis lokalnego pliku i upload artefaktu, a token ma tylko odczyt. Zapisy (blob/tree/commit/PATCH ref) istnieją wyłącznie w preparePullRequest w prepare-version.yml, którego ta zmiana nie dotyczy. prepare dalej ma swoją grupę per PR bez cancel.

• Provenance bez zmian. Provenance przy merge (loadPreparationForMerge) bierze tylko udane runy CI pull_request z artefaktem dla scalonego heada. Ostatni run na tym headzie nie jest anulowany, a mniej runów odsuwa limit per_page=100.

• Slack. notify-slack działa tylko dla push na master, to jedyny job z akcją Slacka. Anulowany run PR nic nie wysyła.

• Test kontraktu (tests/release-workflow.test.ts) przypina:

  • wyrażenie grupy,
  • cancel tylko dla pull_request,
  • brak concurrency na poziomie jobów w ci.yml,
  • cancel-in-progress: false w prepare i publish-npm,
  • Slack tylko z notify-slack i tylko dla push na master.

  Celowe zepsucie (cancel-in-progress: true) daje 1 fail.

Lokalnie przechodzą actionlint, typecheck, lint i 945 testów.

Pomiar

Na tym PR: pierwszy commit (f06465a) uruchomił run 37426760520. Push drugiego commita w trakcie runu sprawił, że run został anulowany (06:57:53 → 06:58:36Z). Run 37426801750 na 87a3271 przeszedł na zielono. Prepare nie dodał bumpu.

Przed zmianą (np. #78): czerwony run 37421708721 na pierwszym commicie dobiegał do końca, a dopiero po nim przychodził zielony 37421752958.

Zachowania na master nie da się sprawdzić na PR. Po merge sprawdzić, czy dwa szybkie merge dają dwa pełne runy z release.

Wersja

Bez bumpu (Prepare nie dodał commita), merge nie publikuje npm.

🤖 Generated with Claude Code

https://claude.ai/code/session_017xPA1vZ4n7nf2yeQmrNBib