OPS64 — pin do waitForChecks contra rollup mentiroso + docs (secundário eliminado estruturalmente pelo OPS62) #79

Merged

fsolla merged 1 commit from OPS64-ops64-forgejo-pr-automerge-waitforchecks-conta-o-propr into main 2026-08-19 15:18:09 +00:00

Conversation 0 Commits 1 Files changed 6 +153 -2

fsolla commented 2026-08-18 23:07:02 +00:00

Owner

Copy link

Closes #62

OPS64 — waitForChecks/rollup honestos. O sintoma primário da Issue (deadlock do waitForChecks no próprio status pending → timeout 30min) já tinha sido entregue pelo OPS61 (filtro do próprio contexto + gate do rollup + PAT + timeouts 45/55 — provado vivo: runs 710/712 do ready-automerge mergearam os PRs #67/#70).

O secundário foi eliminado estruturalmente pelo OPS62. A Issue documentava o bug de agregação de matrix: o Forgejo 9.0.3 reporta o resultado do último shard como o resultado do parent de matrix no contexto needs (runs 604/607/610: e2e (1) vermelho + e2e (2) verde → checks verde), e o needs.<job>.results do GitHub não existe neste runner (act expõe só Outputs/Result). Enquanto este item rodava, o OPS62 mergeou em main e reescreveu ci-pr.yml e ci.yml como jobs únicos sequenciais (sem matrix, sem shards) — o status do job checks agora É o veredito honesto da cascata inteira, e o bug de agregação deixou de existir por construção. O script ci-rollup-check.mjs e os edits de workflow planejados foram descartados no gate (redundantes pós-OPS62 — decisão com o humano; os workflows em main são os do OPS62, intocados).

O que este PR entrega:

• Teste-pino no waitForChecks (tests/unit/forgejoApi.unit.spec.ts, cenário run 607): rollup CI (PR) / checks verde com CI (PR) / e2e (1) vermelho → o CLI lança "Checks falharam". Invariante de defesa: o CLI nunca confia no rollup sozinho — varre os statuses individuais e falha em qualquer failure/error. Vale para sempre e pegaria qualquer matrix que volte a existir.
• Docs honestas (.agents/rules/agent-pr-workflow.mdc, docs/AGENT-OPS.md): a narrativa do parent de matrix (runs 604/607/610), a eliminação estrutural pelo OPS62 e a regra de "nunca agregar via needs num matrix futuro".
• Changelog docs/changelog/2026-08-18-ops64.md + agregado regenerado.

Sem migration/access/Consent/UI/schema. Verificação: unit 2405 verdes; lint/format/typecheck/knip/cycles no gate local; a própria PR prova o ciclo (o ready-automerge mergea no fim).

Impl plan: docs/plans/ops64-forgejo-pr-automerge-waitforchecks-impl.md

Closes #62 **OPS64 — waitForChecks/rollup honestos.** O sintoma primário da Issue (deadlock do `waitForChecks` no próprio status `pending` → timeout 30min) **já tinha sido entregue pelo OPS61** (filtro do próprio contexto + gate do rollup + PAT + timeouts 45/55 — provado vivo: runs 710/712 do `ready-automerge` mergearam os PRs #67/#70). **O secundário foi eliminado estruturalmente pelo OPS62.** A Issue documentava o bug de agregação de matrix: o Forgejo 9.0.3 reporta o resultado do **último shard** como o resultado do parent de matrix no contexto `needs` (runs 604/607/610: `e2e (1)` vermelho + `e2e (2)` verde → `checks` verde), e o `needs.<job>.results` do GitHub **não existe** neste runner (act expõe só `Outputs`/`Result`). Enquanto este item rodava, o **OPS62 mergeou em main** e reescreveu ci-pr.yml e ci.yml como **jobs únicos sequenciais** (sem matrix, sem shards) — o status do job `checks` agora É o veredito honesto da cascata inteira, e o bug de agregação deixou de existir por construção. O script `ci-rollup-check.mjs` e os edits de workflow planejados foram **descartados no gate** (redundantes pós-OPS62 — decisão com o humano; os workflows em main são os do OPS62, intocados). **O que este PR entrega:** - **Teste-pino no `waitForChecks`** (`tests/unit/forgejoApi.unit.spec.ts`, cenário run 607): rollup `CI (PR) / checks` verde **com** `CI (PR) / e2e (1)` vermelho → o CLI **lança** "Checks falharam". Invariante de defesa: o CLI nunca confia no rollup sozinho — varre os statuses individuais e falha em qualquer `failure`/`error`. Vale para sempre e pegaria qualquer matrix que volte a existir. - **Docs honestas** (`.agents/rules/agent-pr-workflow.mdc`, `docs/AGENT-OPS.md`): a narrativa do parent de matrix (runs 604/607/610), a eliminação estrutural pelo OPS62 e a regra de "nunca agregar via `needs` num matrix futuro". - **Changelog** `docs/changelog/2026-08-18-ops64.md` + agregado regenerado. Sem migration/access/Consent/UI/schema. Verificação: unit 2405 verdes; lint/format/typecheck/knip/cycles no gate local; a própria PR prova o ciclo (o `ready-automerge` mergea no fim). Impl plan: `docs/plans/ops64-forgejo-pr-automerge-waitforchecks-impl.md`

fsolla added 1 commit 2026-08-18 23:07:02 +00:00

fix(OPS64): rollup checks honesto por statuses do commit — Forgejo não agrega shards no parent de matrix ... 10c1eeaeda

O sintoma primário da Issue (deadlock do waitForChecks no próprio pending)
já tinha sido entregue pelo OPS61; o OPS64 fecha o secundário, que estava
vivo e medido: o Forgejo 9.0.3 reporta o resultado do ÚLTIMO shard como o
resultado do parent de matrix no contexto `needs` (runs 604/607/610: e2e (1)
vermelho + e2e (2) verde → checks verde), e o `needs.<job>.results` do GitHub
não existe neste runner. Com isso o gate do servidor (branch protection) e o
deploy do ci.yml podiam passar com um shard vermelho.

O rollup `checks` (ci-pr.yml e ci.yml) agora lê os statuses do commit via API
(scripts/ci-rollup-check.mjs + lib pura, zero-dep, plain Node) — a mesma
fonte que o waitForChecks confia — filtrando pelo prefixo do workflow,
excluindo o próprio contexto e os downstreams legítimos (deploy, pending
enquanto o rollup roda), falhando fechado em failure/error/pending/vazio.
Fork guard + FORGEJO_API_TOKEN no job checks do ci-pr.yml (sem o guard, fork
rodaria o script do head com o PAT — RCE classe OPS61); PRs de fork ficam
não-mergeáveis no servidor (hardening). ci.yml usa --allow-empty em
workflow_dispatch (evento não posta commit status).

Testes: 12 specs do veredito (run 607/716 pinados, próprio pending ignorado,
safety net ignorado, deploy ignorado, vazio fail-closed) + waitForChecks
lança com rollup verde + shard vermelho. Unit 2360 verdes; gates locais ok.

fsolla force-pushed OPS64-ops64-forgejo-pr-automerge-waitforchecks-conta-o-propr from 10c1eeaeda to 292369b2b0 2026-08-19 15:11:27 +00:00 Compare

fsolla force-pushed OPS64-ops64-forgejo-pr-automerge-waitforchecks-conta-o-propr from 292369b2b0 to ccfa60c1f2 2026-08-19 15:13:30 +00:00 Compare

fsolla changed title from OPS64 — rollup checks honesto por statuses do commit (Forgejo não agrega shards no parent de matrix) to OPS64 — pin do waitForChecks contra rollup mentiroso + docs (secundário eliminado estruturalmente pelo OPS62) 2026-08-19 15:13:46 +00:00

fsolla merged commit ccfa60c1f2 into main 2026-08-19 15:18:09 +00:00

fsolla referenced this pull request 2026-08-19 15:18:26 +00:00

OPS64 — OPS64 — forgejo-pr-automerge: waitForChecks conta o próprio status pendente (deadlock → timeout 30min, merge nunca acontece pelo safety net) #62

fsolla referenced this pull request 2026-08-19 15:18:30 +00:00

OPS64 — OPS64 — forgejo-pr-automerge: waitForChecks conta o próprio status pendente (deadlock → timeout 30min, merge nunca acontece pelo safety net) #62

fsolla referenced this pull request 2026-08-19 15:22:28 +00:00

OPS64 — OPS64 — forgejo-pr-automerge: waitForChecks conta o próprio status pendente (deadlock → timeout 30min, merge nunca acontece pelo safety net) #62

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

blocked

  

done

  

in-prod

  

in-progress

  

kind:chore

  

prio:P1

  

prio:P2

  

ready

No labels

blocked

done

in-prod

in-progress

kind:chore

prio:P1

prio:P2

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fsolla/teqo#79

No description provided.