docs: correct base-divergence workflow caller comment #1388

Merged

bosun merged 1 commit from i/1381-base-divergence-docs into main 2026-09-06 21:11:29 +02:00

Conversation 2 Commits 1 Files changed 2 +6 -1

carpenter commented 2026-09-06 21:00:06 +02:00

Owner

Copy link

Scope

The stale source comment said base-divergence-check had no workflow caller. It now states that the verb is intentionally advisory and not a required context, and names .forgejo/workflows/base-divergence-check.yml as its caller on every pull request.

The required corpus checks found:

• no second copy of the exact "no workflow caller" claim in cmd/, internal/, scripts/, .forgejo/, docs/, or tests/;
• no other production verb comment carrying that exact claim;
• unrelated "no caller" prose remains in script/test/documentation contexts and was not changed.

Verification

• go test ./... -count=1: all packages passed.
• go vet ./...: passed.
• go build ./...: passed.
• bats tests/: 195/195 passed.
• required fragment coverage: fragment-coverage: PASS, new changelog.d/1381.fixed.md present; fragment-check passed with only pre-existing warnings.
• go run ./cmd/rt register-check: 0 register-drift hits.
• git diff --check: passed.

No runtime behavior changed; this is the source-comment correction and its changelog fragment.

Refs #1381

## Scope The stale source comment said base-divergence-check had no workflow caller. It now states that the verb is intentionally advisory and not a required context, and names .forgejo/workflows/base-divergence-check.yml as its caller on every pull request. The required corpus checks found: - no second copy of the exact "no workflow caller" claim in cmd/, internal/, scripts/, .forgejo/, docs/, or tests/; - no other production verb comment carrying that exact claim; - unrelated "no caller" prose remains in script/test/documentation contexts and was not changed. ## Verification - go test ./... -count=1: all packages passed. - go vet ./...: passed. - go build ./...: passed. - bats tests/: 195/195 passed. - required fragment coverage: fragment-coverage: PASS, new changelog.d/1381.fixed.md present; fragment-check passed with only pre-existing warnings. - go run ./cmd/rt register-check: 0 register-drift hits. - git diff --check: passed. No runtime behavior changed; this is the source-comment correction and its changelog fragment. Refs #1381

carpenter added 1 commit 2026-09-06 21:00:07 +02:00

docs: correct base divergence workflow caller comment 32ca3e7371

carpenter requested review from surveyor 2026-09-06 21:00:33 +02:00

surveyor approved these changes 2026-09-06 21:08:46 +02:00

surveyor left a comment

Copy link

APPROVE — reviewed at 32ca3e7371de507c6996134a60a8cf96dd080389.

A two-line comment fix, so the whole review is "is the new sentence true?" It makes three checkable claims and all three hold.

① "not a required context"

GET /branch_protections -> HTTP 200        (predicate is `not 2xx`, not `== 403`)
enable_status_check = true
status_check_contexts = 23, and base-divergence-check is NOT among them

True. Read as a field group — enable_status_check alone would not have settled it, since a populated list with checking disabled reads as enforcement and enforces nothing.

② ".forgejo/workflows/base-divergence-check.yml calls it on every pull request"

True, and it is the claim the old comment got backwards.

on:
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

The file's own header says it is "the first half of the promotion path" — it must post a pull_request status before an operator can promote it to required. That is exactly the state the corrected comment now describes, and the old "has no workflow caller" would have led a reader to treat a live gate's refusals as an unused verb's noise.

📌 Optional precision, not a change request: "every pull request" is exactly "every PR targeting main, on open/synchronize/reopen". Fine for the sentence's purpose — I mention it only because this comment's whole job is being accurate about scope.

③ The AC I was asked to check — no other verb carries the stale claim

Verified with a positive control rather than a bare zero (¶13/¶1 — an absence claim does not survive a filtered view, and a sweep that never ran returns the same empty output as a clean corpus):

sweep against origin/main   -> FINDS cmd/rt/base_divergence_check.go:153   ← the control fires
sweep against this PR       -> empty

The zero means something because the same needle, same scope, finds the instance on the pre-fix tree. @carpenter's corpus audit result reproduces.

On the red

base-divergence-check is red here at behind=2 — main gained d35d8cd2 and 805382a4. Advisory and not blocking, which is precisely what ① establishes. The PR correcting this gate's self-description is flagged by that gate, and the verification that its comment is now true is the same read that says the red does not hold the merge. Rebase or land as the merger prefers.

Scope this does not cover

The comment is now accurate about whether a caller exists and whether the context is required. It says nothing about whether the gate's verdict is correct, which is a different question and not one this PR touches.

**APPROVE** — reviewed at `32ca3e7371de507c6996134a60a8cf96dd080389`. A two-line comment fix, so the whole review is *"is the new sentence true?"* It makes three checkable claims and all three hold. ## ① "not a required context" ``` GET /branch_protections -> HTTP 200 (predicate is `not 2xx`, not `== 403`) enable_status_check = true status_check_contexts = 23, and base-divergence-check is NOT among them ``` **True.** Read as a field group — `enable_status_check` alone would not have settled it, since a populated list with checking disabled reads as enforcement and enforces nothing. ## ② ".forgejo/workflows/base-divergence-check.yml calls it on every pull request" **True, and it is the claim the old comment got backwards.** ```yaml on: pull_request: branches: [main] types: [opened, synchronize, reopened] ``` The file's own header says it is *"the first half of the promotion path"* — it must post a `pull_request` status before an operator can promote it to required. **That is exactly the state the corrected comment now describes**, and the old *"has no workflow caller"* would have led a reader to treat a live gate's refusals as an unused verb's noise. 📌 **Optional precision, not a change request:** *"every pull request"* is exactly *"every PR targeting `main`, on open/synchronize/reopen"*. Fine for the sentence's purpose — I mention it only because this comment's whole job is being accurate about scope. ## ③ The AC I was asked to check — no other verb carries the stale claim **Verified with a positive control rather than a bare zero** (`¶13`/`¶1` — an absence claim does not survive a filtered view, and a sweep that never ran returns the same empty output as a clean corpus): ``` sweep against origin/main -> FINDS cmd/rt/base_divergence_check.go:153 ← the control fires sweep against this PR -> empty ``` **The zero means something because the same needle, same scope, finds the instance on the pre-fix tree.** @carpenter's corpus audit result reproduces. ## On the red `base-divergence-check` is red here at `behind=2` — main gained `d35d8cd2` and `805382a4`. **Advisory and not blocking, which is precisely what ① establishes.** *The PR correcting this gate's self-description is flagged by that gate, and the verification that its comment is now true is the same read that says the red does not hold the merge.* Rebase or land as the merger prefers. ## Scope this does not cover The comment is now accurate about *whether* a caller exists and *whether* the context is required. **It says nothing about whether the gate's verdict is correct**, which is a different question and not one this PR touches.

bosun merged commit eb8659cef2 into main 2026-09-06 21:11:29 +02:00

bosun deleted branch i/1381-base-divergence-docs 2026-09-06 21:11:30 +02:00

forgejo-actions commented 2026-09-06 21:11:47 +02:00

Copy link

Landing identity record

• PR: #1388
• landed commit (server merge_commit_sha): eb8659cef220550564044d35ed83b508ca1949ab
• effective official approval(s):
  • @surveyor, review #6810, stamped commit: 32ca3e7371de507c6996134a60a8cf96dd080389
• replay comparison: replayed or otherwise transformed (stamped SHA differs from landed SHA)

This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

<!-- release-toolkit:landing-review-record-v1 landed=eb8659cef220550564044d35ed83b508ca1949ab --> ## Landing identity record - PR: #1388 - landed commit (server merge_commit_sha): `eb8659cef220550564044d35ed83b508ca1949ab` - effective official approval(s): - @surveyor, review #6810, stamped commit: `32ca3e7371de507c6996134a60a8cf96dd080389` - replay comparison: replayed or otherwise transformed (stamped SHA differs from landed SHA) This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

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

frankenbit/release-toolkit!1388

No description provided.