diff --git a/docs/PRODUCTION_UPDATER_3_4.md b/docs/PRODUCTION_UPDATER_3_4.md index 5ab4669..20db39e 100644 --- a/docs/PRODUCTION_UPDATER_3_4.md +++ b/docs/PRODUCTION_UPDATER_3_4.md @@ -125,7 +125,7 @@ Für jeden aktuellen PR-Head werden ausgewertet: - `statusCheckRollup` des Pull Requests, - Workflow-Runs aus `actions/runs?head_sha=&per_page=100`, -- die Pflichtchecks `Syntax, Sicherheit und Release-Gates` sowie `Windows – vollständiger Releasevertrag`, +- die Pflichtchecks `Syntax, Sicherheit und Release-Gates`, `Windows – vollständiger Releasevertrag` und `Updater-3.4-Paket nach Abnahme`, - die Pflichtworkflows `Vendoo CI` und `Vendoo Release Manifest Sync`. Regeln: @@ -137,6 +137,19 @@ Regeln: - Vor dem Merge wird der Head-SHA erneut gelesen. - Der Merge verwendet `--match-head-commit`; ein weiterer Headwechsel verhindert den Merge atomar. +### Final-Head-Registrierung nach Manifest-Sync + +Ein Push mit dem GitHub-Workflow-Token startet für den dadurch erzeugten Commit nicht automatisch einen weiteren Push-Workflow. Deshalb bestätigt der Manifest-Sync nach seinem Commit zuerst den tatsächlichen Remote-Head und dispatcht anschließend explizit: + +1. `Vendoo CI` für den neuen Head, +2. `Vendoo Release Manifest Sync` für denselben Head. + +Der zweite Manifest-Sync-Lauf findet ein unverändertes Manifest, erzeugt keinen weiteren Commit und dient als konkreter erfolgreicher Workflow-Nachweis am finalen SHA. Die Concurrency des Sync-Workflows darf den auslösenden Lauf nicht abbrechen. + +### Paket erst nach Plattformabnahme + +Das auslieferbare ZIP entsteht im Job `Updater-3.4-Paket nach Abnahme`. Dieser Job besitzt eine harte `needs`-Abhängigkeit auf Linux- und Windows-Abnahme. Er läuft daher erst, wenn beide Verträge erfolgreich abgeschlossen wurden. Danach werden Root-Manifest, Paketmanifest v2, Zielversion, Updater-Version und ZIP-SHA-256 erneut geprüft. Nur dieses Artefakt ist ein auslieferbarer Kandidat. + ## Sitzungsvertrag Sitzungen verwenden `vendoo-updater-session-v2`. Die Identität besteht aus: