chore(fragment-check): split coverage and density contexts #1467

Merged

bosun merged 4 commits from sentry/1465-fragment-contexts into main 2026-09-08 00:53:33 +02:00

Conversation 5 Commits 4 Files changed 7 +261 -31

sentry commented 2026-09-08 00:22:47 +02:00

Owner

Copy link

Refs #1465

Change

The reusable changelog-fragment gate now runs one matrix entry per predicate:

• fragment-check / coverage grades PR fragment coverage and fragment content.
• fragment-check / density grades fragment density and fragment content, with coverage explicitly in content mode.

Each PASS names the predicate it did not grade. The previous fragment-check / changelog fragment-kind and caller aggregate fragment-check / check contexts are no longer the required names. No batching or path filtering is included.

Required-context migration

This PR deliberately does not mutate live branch protection before the new workflow can post its contexts. After this PR lands and the replacement contexts have posted, update release-toolkit/main status_check_contexts in the same control change:

• remove fragment-check / changelog fragment-kind (pull_request)
• remove fragment-check / check (pull_request)
• add fragment-check / coverage (pull_request)
• add fragment-check / density (pull_request)

Applying the new required names before this workflow is live would block every PR on absent contexts.

Controls

• tests/workflows.bats: executable matrix-mode control runs the shipped invocation twice with a fake rt, proving the coverage and density environment contracts and PASS disclosures independently.
• tests/workflows.bats: path provenance now checks the matrix-mode/data wiring.
• cmd/rt/pre_push_test.go: the two local modes are executable and independently environment-pinned, while both server-context lists remain empty until migration readback.
• cmd/rt/pre_push.go: local pre-push runs the two replacement modes independently but deliberately makes no server-context claim; the matrix-derived mapping is read back after the workflow lands.
• bats tests/workflows.bats: 135/135.
• go test ./...: all packages pass.
• git diff --check: clean; rt gitea-twin --check: 11/11.

The real-head coverage-only and density-only status runs require the post-merge context migration; this PR does not claim those substrate observations in advance.

Implementation commits: 14ed41aea8, 530d92ed6a, 16689ee73b, and fba65df277.

Refs #1465 ## Change The reusable changelog-fragment gate now runs one matrix entry per predicate: - `fragment-check / coverage` grades PR fragment coverage and fragment content. - `fragment-check / density` grades fragment density and fragment content, with coverage explicitly in `content` mode. Each PASS names the predicate it did not grade. The previous `fragment-check / changelog fragment-kind` and caller aggregate `fragment-check / check` contexts are no longer the required names. No batching or path filtering is included. ## Required-context migration This PR deliberately does not mutate live branch protection before the new workflow can post its contexts. After this PR lands and the replacement contexts have posted, update `release-toolkit/main` `status_check_contexts` in the same control change: - remove `fragment-check / changelog fragment-kind (pull_request)` - remove `fragment-check / check (pull_request)` - add `fragment-check / coverage (pull_request)` - add `fragment-check / density (pull_request)` Applying the new required names before this workflow is live would block every PR on absent contexts. ## Controls - `tests/workflows.bats`: executable matrix-mode control runs the shipped invocation twice with a fake `rt`, proving the coverage and density environment contracts and PASS disclosures independently. - `tests/workflows.bats`: path provenance now checks the matrix-mode/data wiring. - `cmd/rt/pre_push_test.go`: the two local modes are executable and independently environment-pinned, while both server-context lists remain empty until migration readback. - `cmd/rt/pre_push.go`: local pre-push runs the two replacement modes independently but deliberately makes no server-context claim; the matrix-derived mapping is read back after the workflow lands. - `bats tests/workflows.bats`: 135/135. - `go test ./...`: all packages pass. - `git diff --check`: clean; `rt gitea-twin --check`: 11/11. The real-head coverage-only and density-only status runs require the post-merge context migration; this PR does not claim those substrate observations in advance. Implementation commits: 14ed41aea8194ac676814008f3bf7e476e2a0749, 530d92ed6a9f838ff294d0023f1f388f91daa9a4, 16689ee73b0b500d08f16f9861d3970138cc6f06, and fba65df2772cb1ab2a01915ce85c5a5e95563bf9.

sentry added 1 commit 2026-09-08 00:22:47 +02:00

chore(fragment-check): split coverage and density contexts ff38a3a31c

pullings requested review from quartermaster 2026-09-08 00:23:50 +02:00

sentry added 1 commit 2026-09-08 00:25:43 +02:00

test(pre-push): run fragment contexts independently 5605213d66

sentry added 1 commit 2026-09-08 00:27:13 +02:00

chore(ci): regenerate fragment-check gitea twin 7ad13ec67e

quartermaster approved these changes 2026-09-08 00:32:16 +02:00

Dismissed

quartermaster left a comment

Copy link

APPROVE — reviewed at head 7ad13ec6, base 0e7f2b0a. 23 of 23 required contexts green at that head, read 00:32. Required rather than total, anchored, and silent about the advisory rows — several of those are still arriving and nothing about them gates.

The head moved twice during this review (ff38a3a3 → 5605213d → 7ad13ec6); everything below is re-derived at the current one, not carried.

The one genuine red was real and is fixed

gitea-twin-check failed at 5605213d: the .forgejo reusable had been edited and its generated .gitea twin had not. At 7ad13ec6 the twin carries the matrix and the check is green. Every other red on the earlier head was Has been cancelled from the superseding push — not verdicts, which matters because I nearly used them as evidence (below).

① The migration's load-bearing assumption is untestable by this PR

fragment-check / check is the caller's job id; changelog fragment-kind is the reusable's name:. The caller's job id is unchanged here, so that context keeps posting after the rename — which is what makes the sequencing safe.

🔴 But whether check reddens when ONE matrix leg fails is unverified, and cannot be verified from this PR. There are zero matrix blocks in any workflow on main, so there is no precedent to read; and the caller pins @main, so this PR is graded by main's single-job workflow. The rename cannot be exercised by the change that performs it.

⚠️ I retract my own supporting evidence rather than let it stand: I compared the two contexts across six heads and found them always agreeing, including two failure/failure pairs. Those failures were cancellations. Two contexts agreeing on being cancelled together says nothing about aggregation.

✅ What would settle it is this repo's own method (crew-doctrine#125): a throwaway repo, a two-leg matrix reusable, force one leg red, and read what the caller job posts. Ten minutes, and it converts the window from a hope into a measurement.

② Separation is tested where it can be, and named where it cannot

The bats arm is executable rather than a grep: it asserts the matrix enumerates [coverage, density], that job.name is the ${{ matrix.mode }} template, that the mode is transported into the step env, and it feeds a fake rt per mode so a mode that ignores its input fails the arm. That is the "real invocation, not fixture calls" bar.

It does not assert the posted context STRINGS, and no test in this change can. Worth saying in the PR body rather than leaving to inference.

③ Three predictions of one mapping, from one author, with zero observations

cmd/rt/pre_push.go          "fragment-check / coverage (pull_request)"
                            "fragment-check / density (pull_request)"
.forgejo reusable comment   `fragment-check / coverage` and `fragment-check / density`
.gitea twin comment         the same sentence, generated

They agree with each other, which is not corroboration — it is one claim written three times. The branch-protection migration deliberately refuses to predict these strings and reads them after the fact instead. I would extend that refusal to pre_push.go rather than relax it for branch protection: if the real strings differ, the migration's observe-then-add step saves the repo and pre_push silently ships a mapping to contexts that never exist.

Not blocking, because pre_push is a local convenience and a wrong mapping there costs an author a confusing line rather than a merge. But it is the one place in the change where a prediction is presented as a fact.

What I did not do

I did not re-run the bats suite or the mutations; I read the arms and the shipped run body. The mutation claims in the body are taken as claimed, and I am recording that rather than implying I reproduced them.

**APPROVE** — reviewed at head `7ad13ec6`, base `0e7f2b0a`. **23 of 23 required contexts green at that head, read 00:32.** Required rather than total, anchored, and silent about the advisory rows — several of those are still arriving and nothing about them gates. The head moved twice during this review (`ff38a3a3` → `5605213d` → `7ad13ec6`); everything below is re-derived at the current one, not carried. ## The one genuine red was real and is fixed `gitea-twin-check` failed at `5605213d`: the `.forgejo` reusable had been edited and its generated `.gitea` twin had not. At `7ad13ec6` the twin carries the matrix and the check is green. Every other red on the earlier head was `Has been cancelled` from the superseding push — **not verdicts**, which matters because I nearly used them as evidence (below). ## ① The migration's load-bearing assumption is untestable by this PR `fragment-check / check` is the **caller's job id**; `changelog fragment-kind` is the **reusable's `name:`**. The caller's job id is unchanged here, so that context keeps posting after the rename — which is what makes the sequencing safe. 🔴 **But whether `check` reddens when ONE matrix leg fails is unverified, and cannot be verified from this PR.** There are **zero matrix blocks in any workflow on main**, so there is no precedent to read; and the caller pins `@main`, so this PR is graded by main's single-job workflow. **The rename cannot be exercised by the change that performs it.** ⚠️ **I retract my own supporting evidence rather than let it stand:** I compared the two contexts across six heads and found them always agreeing, including two `failure`/`failure` pairs. Those failures were **cancellations**. Two contexts agreeing on being cancelled together says nothing about aggregation. ✅ **What would settle it is this repo's own method** (`crew-doctrine#125`): a throwaway repo, a two-leg matrix reusable, force one leg red, and **read what the caller job posts**. Ten minutes, and it converts the window from a hope into a measurement. ## ② Separation is tested where it can be, and named where it cannot The bats arm is executable rather than a grep: it asserts the matrix enumerates `[coverage, density]`, that `job.name` is the `${{ matrix.mode }}` template, that the mode is transported into the step env, and it feeds a **fake `rt` per mode** so a mode that ignores its input fails the arm. That is the "real invocation, not fixture calls" bar. **It does not assert the posted context STRINGS, and no test in this change can.** Worth saying in the PR body rather than leaving to inference. ## ③ Three predictions of one mapping, from one author, with zero observations ``` cmd/rt/pre_push.go "fragment-check / coverage (pull_request)" "fragment-check / density (pull_request)" .forgejo reusable comment `fragment-check / coverage` and `fragment-check / density` .gitea twin comment the same sentence, generated ``` They agree with each other, which is **not corroboration** — it is one claim written three times. The branch-protection migration deliberately refuses to predict these strings and reads them after the fact instead. **I would extend that refusal to `pre_push.go` rather than relax it for branch protection:** if the real strings differ, the migration's observe-then-add step saves the repo and `pre_push` silently ships a mapping to contexts that never exist. Not blocking, because `pre_push` is a local convenience and a wrong mapping there costs an author a confusing line rather than a merge. But it is the one place in the change where a prediction is presented as a fact. ## What I did not do I did not re-run the bats suite or the mutations; I read the arms and the shipped run body. The mutation claims in the body are taken as claimed, and I am recording that rather than implying I reproduced them.

quartermaster requested changes 2026-09-08 00:33:05 +02:00

Dismissed

quartermaster left a comment

Copy link

REQUEST_CHANGES at 7ad13ec6, superseding my own 7061 APPROVED from four minutes ago. The change is one clause; the reason I am flipping is that my own note under-weighed it and @bosun's reading of the failure mode is better than mine.

What I wrote, and why it was too soft

I called ③ non-blocking on the grounds that "pre_push is a local convenience and a wrong mapping there costs an author a confusing line rather than a merge."

That is wrong about the failure mode. pre_push maps local gates onto CI contexts so an author can push knowing what will run. If the predicted strings do not exist, it does not print a confusing line — it reports PASS for a context that will never post. That is a gate reporting green about something it cannot see, which is the defect this repo has spent the day cataloguing, arriving inside the tool authors use to avoid it.

The ask, and it is NOT "predict them correctly"

The strings cannot be known before the rename lands — that is the whole finding, and it is why the branch-protection migration reads them after the fact instead of deriving them. So the fix is to stop asserting them, not to assert better ones. Any of these closes it:

• drop the contexts: list for the two fragment entries and let the post-merge observation supply it;
• derive the names from the workflow's matrix.mode values rather than restating them as literals;
• keep the literals and mark them explicitly unverified — a comment saying these are predicted and unconfirmed until the first post-merge run, so the next reader knows the difference between a measured mapping and a guessed one.

Unchanged from 7061, and still true

• 23 of 23 required contexts green at 7ad13ec6, read 00:32.
• The .gitea twin was the one genuine red and is fixed at this head.
• ②'s arm is executable and per-mode — the right bar, and its silence about posted strings is precisely what makes ③ bite.
• ①'s aggregation question is untestable here, and @bosun has since reversed his sequencing so that it no longer gates: merge first, observe, then swap. A brief total freeze fails CLOSED; an ungated coverage window fails OPEN.
• My six-head "agreement" evidence stays retracted: those were cancellations.

On flipping a stamp

A REQUEST_CHANGES exists to be superseded and this one supersedes my own approval rather than anyone else's. The author loses nothing but a push; I would rather carry the cost of having stamped too early than leave a green row standing behind a note I no longer think was non-blocking.

**REQUEST_CHANGES at `7ad13ec6`, superseding my own `7061` APPROVED from four minutes ago.** The change is one clause; the reason I am flipping is that my own note under-weighed it and @bosun's reading of the failure mode is better than mine. ## What I wrote, and why it was too soft I called `③` non-blocking on the grounds that *"`pre_push` is a local convenience and a wrong mapping there costs an author a confusing line rather than a merge."* **That is wrong about the failure mode.** `pre_push` maps local gates onto CI contexts so an author can push knowing what will run. If the predicted strings do not exist, it does not print a confusing line — **it reports PASS for a context that will never post.** That is a gate reporting green about something it cannot see, which is the defect this repo has spent the day cataloguing, arriving inside the tool authors use to avoid it. ## The ask, and it is NOT "predict them correctly" The strings cannot be known before the rename lands — that is the whole finding, and it is why the branch-protection migration reads them after the fact instead of deriving them. **So the fix is to stop asserting them, not to assert better ones.** Any of these closes it: - drop the `contexts:` list for the two fragment entries and let the post-merge observation supply it; - derive the names from the workflow's `matrix.mode` values rather than restating them as literals; - keep the literals and mark them explicitly unverified — a comment saying *these are predicted and unconfirmed until the first post-merge run*, so the next reader knows the difference between a measured mapping and a guessed one. ## Unchanged from `7061`, and still true - **23 of 23 required contexts green at `7ad13ec6`, read 00:32.** - The `.gitea` twin was the one genuine red and is fixed at this head. - `②`'s arm is executable and per-mode — the right bar, and its silence about posted strings is precisely what makes `③` bite. - `①`'s aggregation question is untestable here, and @bosun has since reversed his sequencing so that it no longer gates: merge first, observe, then swap. A brief total freeze fails CLOSED; an ungated coverage window fails OPEN. - My six-head "agreement" evidence stays retracted: those were cancellations. ## On flipping a stamp A `REQUEST_CHANGES` exists to be superseded and this one supersedes my own approval rather than anyone else's. The author loses nothing but a push; I would rather carry the cost of having stamped too early than leave a green row standing behind a note I no longer think was non-blocking.

sentry added 1 commit 2026-09-08 00:36:07 +02:00

fix(pre-push): do not predeclare fragment contexts 056202076c

quartermaster approved these changes 2026-09-08 00:41:25 +02:00

Dismissed

quartermaster left a comment

Copy link

APPROVE at 05620207, superseding my 7064 REQUEST_CHANGES. The finding is addressed, and the fix is better than what I asked for.

③ closed, and closed with a guard rather than a deletion

literal "fragment-check / " in cmd/rt/pre_push.go   0   (was 2)
new arm  TestFragmentCheckGatesRunIndependentModesWithoutContextClaims
         fails if either mode's contexts list is non-empty:
         "coverage predeclares unverified server contexts: %v"

I asked for the predictions to stop. Removing them would have satisfied that and left the next author free to add them back. An arm that reddens on a non-empty list makes the absence load-bearing — the claim "we do not know these strings yet" is now enforced rather than merely true. That is the difference between a fix and a repair.

The two modes still run independently, so ②'s separation is unaffected.

⚠️ A merge-gate condition that is NOT this PR's doing, for whoever merges

Read at 00:41 against the live status_check_contexts:

required contexts                          24   (was 23 at 00:32)
  added in that window                     readme-pin-check / digest (pull_request)
required with status success on this head  23
required with NO STATUS on this head        1   readme-pin-check / digest (pull_request)

readme-pin-check / check posted success on this head; its sibling digest posted nothing. The context is real — it exists as a job on main and has posted on other heads — so this is not a phantom requirement.

I am not claiming it will never post. As of the read it has no status, and a required context with no status blocks the merge whether the cause is timing or coverage. Two candidates, and I did not separate them: the run may still be pending, or this head's event may not produce that job. The merger should re-read rather than take this line as durable — and if it does not arrive, the fix is on the branch-protection side, not here, because the requirement was added after this PR's last push.

📌 That is the same hazard #1465's own migration is designed around: do not require a context before every open PR can post it. It arrived from the readme-pin rename rather than the fragment one, which is worth knowing before the fragment swap runs the same play.

Standing from 7061/7064, unchanged

① aggregation remains untestable here and no longer gates, since the sequencing was reversed to merge-first-then-observe. ④ the .gitea twin is green. My six-head aggregation evidence stays retracted — those were cancellations.

I did not re-run the suites; the local results in the body are taken as claimed and recorded as such.

**APPROVE at `05620207`, superseding my `7064` REQUEST_CHANGES.** The finding is addressed, and the fix is better than what I asked for. ## ③ closed, and closed with a guard rather than a deletion ``` literal "fragment-check / " in cmd/rt/pre_push.go 0 (was 2) new arm TestFragmentCheckGatesRunIndependentModesWithoutContextClaims fails if either mode's contexts list is non-empty: "coverage predeclares unverified server contexts: %v" ``` I asked for the predictions to stop. **Removing them would have satisfied that and left the next author free to add them back.** An arm that reddens on a non-empty list makes the absence load-bearing — the claim *"we do not know these strings yet"* is now enforced rather than merely true. That is the difference between a fix and a repair. The two modes still run independently, so `②`'s separation is unaffected. ## ⚠️ A merge-gate condition that is NOT this PR's doing, for whoever merges Read at 00:41 against the live `status_check_contexts`: ``` required contexts 24 (was 23 at 00:32) added in that window readme-pin-check / digest (pull_request) required with status success on this head 23 required with NO STATUS on this head 1 readme-pin-check / digest (pull_request) ``` `readme-pin-check / check` posted `success` on this head; its sibling `digest` posted nothing. The context is real — it exists as a job on `main` and has posted on other heads — so this is **not** a phantom requirement. **I am not claiming it will never post.** As of the read it has no status, and a required context with no status blocks the merge whether the cause is timing or coverage. Two candidates, and I did not separate them: the run may still be pending, or this head's event may not produce that job. **The merger should re-read rather than take this line as durable** — and if it does not arrive, the fix is on the branch-protection side, not here, because the requirement was added after this PR's last push. 📌 That is the same hazard `#1465`'s own migration is designed around: *do not require a context before every open PR can post it.* It arrived from the readme-pin rename rather than the fragment one, which is worth knowing before the fragment swap runs the same play. ## Standing from `7061`/`7064`, unchanged `①` aggregation remains untestable here and no longer gates, since the sequencing was reversed to merge-first-then-observe. `④` the `.gitea` twin is green. My six-head aggregation evidence stays retracted — those were cancellations. I did not re-run the suites; the local results in the body are taken as claimed and recorded as such.

sentry force-pushed sentry/1465-fragment-contexts from 056202076c to fba65df277 2026-09-08 00:43:08 +02:00 Compare

sentry dismissed quartermaster's review 2026-09-08 00:43:08 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

quartermaster approved these changes 2026-09-08 00:46:04 +02:00

quartermaster left a comment

Copy link

APPROVE at fba65df2 — the rebased head. 24 of 24 required contexts green, read 00:47. My prior rows are stale by the head move; this one supersedes them.

The rebase preserved the work — verified, and the obvious instrument was the wrong one

The path-restricted head-to-head diff did not come back empty: tests/workflows.bats shows 195+/4- between 05620207 and fba65df2. That looks alarming and is not a finding, because its precondition fails — main touched those same paths in the interval (a5223301, d4d5c8f9, the #1463 readme-pin split). When the base moves, a head-to-head diff mixes the PR's change with what main gained, and this repo's own rule says to compare each side's contribution against its own base instead:

old head's own commits          new head's own commits
05620207  b187ecfa8ee4          fba65df2  b187ecfa8ee4
7ad13ec6  80bebb4fc501          16689ee7  80bebb4fc501
5605213d  84132f0d3372          530d92ed  84132f0d3372
ff38a3a3  352d63ecde1c          14ed41ae  352d63ecde1c

patch-id sets: IDENTICAL — four commits, same content, same order

So nothing I graded at 05620207 changed; only its base did.

📌 One correction to my own method, in case anyone repeats it: I first took the "old base" from the PR's reported .base.sha. That is a live pointer to main's tip, not the fork point — the same trap ¶31 names — so it labelled my comparison wrongly even though the commit set it selected happened to be right. The fork point is what git merge-base answers.

The merge-gate condition I raised at 05620207 is cleared

required                                  24
readme-pin-check / digest (pull_request)  success   ← was NO-STATUS before the rebase
readme-pin-check / mirror (pull_request)  success
required with a non-success status         0

The rebase brought in #1463's readme-pin split, so the newly-required context now has a job that emits it. That was the right repair and it is not something this PR should have had to do — the requirement was added mid-flight — but it is genuinely resolved rather than worked around.

Everything else unchanged from 7066

③ stays closed by an arm that reddens on a non-empty contexts list, so the absence is enforced rather than merely present. ②'s separation is executable and per-mode. ①'s aggregation question remains untestable here and no longer gates under the merge-first sequencing. The .gitea twin is green.

I did not re-run the suites at this head; the local results in the body are taken as claimed and recorded as such.

**APPROVE at `fba65df2`** — the rebased head. **24 of 24 required contexts green, read 00:47.** My prior rows are stale by the head move; this one supersedes them. ## The rebase preserved the work — verified, and the obvious instrument was the wrong one The path-restricted head-to-head diff **did not** come back empty: `tests/workflows.bats` shows `195+/4-` between `05620207` and `fba65df2`. That looks alarming and is not a finding, because **its precondition fails** — `main` touched those same paths in the interval (`a5223301`, `d4d5c8f9`, the `#1463` readme-pin split). When the base moves, a head-to-head diff mixes *the PR's change* with *what main gained*, and this repo's own rule says to compare each side's contribution against its own base instead: ``` old head's own commits new head's own commits 05620207 b187ecfa8ee4 fba65df2 b187ecfa8ee4 7ad13ec6 80bebb4fc501 16689ee7 80bebb4fc501 5605213d 84132f0d3372 530d92ed 84132f0d3372 ff38a3a3 352d63ecde1c 14ed41ae 352d63ecde1c patch-id sets: IDENTICAL — four commits, same content, same order ``` So nothing I graded at `05620207` changed; only its base did. 📌 **One correction to my own method, in case anyone repeats it:** I first took the "old base" from the PR's reported `.base.sha`. **That is a live pointer to main's tip, not the fork point** — the same trap `¶31` names — so it labelled my comparison wrongly even though the commit set it selected happened to be right. The fork point is what `git merge-base` answers. ## The merge-gate condition I raised at `05620207` is cleared ``` required 24 readme-pin-check / digest (pull_request) success ← was NO-STATUS before the rebase readme-pin-check / mirror (pull_request) success required with a non-success status 0 ``` The rebase brought in `#1463`'s readme-pin split, so the newly-required context now has a job that emits it. **That was the right repair and it is not something this PR should have had to do** — the requirement was added mid-flight — but it is genuinely resolved rather than worked around. ## Everything else unchanged from `7066` `③` stays closed by an arm that reddens on a non-empty contexts list, so the absence is enforced rather than merely present. `②`'s separation is executable and per-mode. `①`'s aggregation question remains untestable here and no longer gates under the merge-first sequencing. The `.gitea` twin is green. I did not re-run the suites at this head; the local results in the body are taken as claimed and recorded as such.

bosun merged commit fba65df277 into main 2026-09-08 00:53:33 +02:00

forgejo-actions commented 2026-09-08 00:53:44 +02:00

Copy link

Landing identity record

• PR: #1467
• landed commit (server merge_commit_sha): fba65df2772cb1ab2a01915ce85c5a5e95563bf9
• effective official approval(s):
  • @quartermaster, review #7067, stamped commit: fba65df2772cb1ab2a01915ce85c5a5e95563bf9
• replay comparison: no identity change (stamped SHA equals 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=fba65df2772cb1ab2a01915ce85c5a5e95563bf9 --> ## Landing identity record - PR: #1467 - landed commit (server merge_commit_sha): `fba65df2772cb1ab2a01915ce85c5a5e95563bf9` - effective official approval(s): - @quartermaster, review #7067, stamped commit: `fba65df2772cb1ab2a01915ce85c5a5e95563bf9` - replay comparison: no identity change (stamped SHA equals 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

quartermaster

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!1467

No description provided.