After a takeover at a new revision, the taking run posts another "Round 1" on the PR

Aperta
  • Qualcosa non va?
#463 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Read the decision record for #414 and check the takeover behavior introduced by PR #460. Decide whether a taking run should continue round numbering from the PR, change only the displayed title, or keep per-run numbering and document it. Done means recording a rule that respects the stated identity and ownership constraints.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Follow-up to #414, deferred by its decision record under Residuals. It applies once PR #460 merges.

Problem

A fresh run that takes a PR over with unblock --take-over starts its review history at round 0. The review comment's identity is the round, HEAD, base and merge base, and #414 deliberately leaves that unchanged. At the same revision, D9.6 refuses a second round 1. At a new revision the identities differ, so the taking run posts another "Round 1" on a PR that already has one, and its later rounds repeat numbers too.

Impact

This does not affect safety: merging still requires the taking run's own review certificate. The cost is to readers. A PR's comments can show two series of rounds, and a finding id such as R1-F1 can then name two different findings on one PR.

Starting from round 0 also starts the taking run's workflow.max_review_rounds budget afresh, so the cap applies per run rather than per PR. Whether that matters is part of this decision.

Constraints

  • The comment's identity must not gain a run id. Otherwise two runs' round-1 comments would each count as "this round's" and both would post (#414, Constraints).
  • A fresh run must not treat another run's findings, verdicts or certificates as its own. That rules out simply inheriting the earlier state.
  • An operator may also reasonably want the round count to stay per run, since each run's reviewer sees only its own history.

Desired outcome

A rule for what a taking run's rounds are called, or a decision that the current numbering stays and is documented. Options include starting from the highest round found on the PR, or changing how the comment's title shows the round without changing its marker identity.

Unknowns

How often takeovers will happen in practice. Today the expected case is the one-time stop at the upgrade, and a run rebinding its own PR keeps its round count, so this affects only a fresh run's takeover at a new revision.

Lingua principale
Python
Stelle
0
Fork
0
Merge medio
6h 7m
PR unite (30g)
107

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 iceboundrock/AutoForge

Tutte le issue di iceboundrock/AutoForge

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.