fix: retry Gitea PaC webhook mirror sync

2026-07-09 15:15:55 +02:00
parent 07b69e7b10
commit 99b394691b
4 changed files with 69 additions and 5 deletions
@@ -45,6 +45,8 @@ Use `bun scripts/cli.ts platform-infra pipelines-as-code history --target <NODE>

 GitHub webhook delivery `202` only means the bridge accepted the event. If `platform-infra gitea mirror webhook status --target <NODE>` shows `STALE=true`, treat the bridge event as stale and run the row's `REPAIR` command; the repair path is still the controlled `platform-infra gitea mirror sync --target <NODE> --repo <key> --confirm` entry and must not be replaced with a direct Gitea push.

+The GitHub -> Gitea bridge must use YAML-declared bounded retry for its asynchronous `git fetch` and Gitea `push` worker. Retry ownership is `config/platform-infra/gitea.yaml#sourceAuthority.webhookSync.bridge.retry`; `webhook status` should show the active retry shape in the default summary. A GitHub delivery returning 202 is not enough to close a rollout or issue unless Gitea branch, snapshot ref and the latest bridge event are also aligned to GitHub head.
+
 Do not use `cicd branch-follower status` to decide whether the three migrated JD01 consumers are current. It is historical/migration-only and may contain stale state from before PaC cutover.

 For migrated sentinel CI/CD half-state triage, the PaC `status` command owns the source/registry/GitOps/Argo/runtime diagnosis. It must classify registry-missing, GitOps-missing, Argo-pending and runtime-mismatch states from target-side short probes, using YAML-declared probe endpoints such as `registry_probe_base`; do not reintroduce old control-plane status as the primary architecture or use registry manifest `HEAD` as the readiness check.