fix(fragment-check): allow consumer valid-kind set #494

Merged

bosun merged 1 commit from carpenter/489-fragment-check-valid-kinds into main 2026-07-23 23:55:07 +02:00 AGit

Conversation 4 Commits 1 Files changed 5 +61 -5

carpenter commented 2026-07-23 23:27:16 +02:00

Owner

Copy link

Fixes #489.

Trace result: release-toolkit's own fragment backend is internally consistent around internal (scripts/lib/fragments.sh, release-decision bumping, docs, and tests all agree). The contradiction appears when the reusable PR-time fragment gate is used by a consumer whose release-time assembler has a different authoritative type set; tmux-tell's in-repo tools/changelog-assemble accepts documentation and rejects internal.

Fix: keep release-toolkit's default valid-kind set unchanged, but make the reusable/script gate configurable so consumers can align the PR-time validator with their release-time assembler:

• reusable-changelog-fragment-check.yml gains valid_kinds, defaulting to added changed deprecated removed fixed security internal
• scripts/fragment-check.sh accepts FRAGMENT_CHECK_KINDS and applies it to the existing assert_no_unknown_kinds path
• docs show the tmux-tell-style override: added changed deprecated removed fixed security documentation
• bats tests pin both sides: .documentation.md passes with the custom set, and .internal.md is rejected under that same custom set

Verification:

• bash -n scripts/fragment-check.sh
• shellcheck -x scripts/fragment-check.sh
• bats tests/fragment-check.bats
• bats tests/fragment-check.bats tests/fragments.bats tests/workflows.bats
• bats tests/ (771 tests)

Fixes #489. Trace result: release-toolkit's own fragment backend is internally consistent around `internal` (`scripts/lib/fragments.sh`, release-decision bumping, docs, and tests all agree). The contradiction appears when the reusable PR-time fragment gate is used by a consumer whose release-time assembler has a different authoritative type set; tmux-tell's in-repo `tools/changelog-assemble` accepts `documentation` and rejects `internal`. Fix: keep release-toolkit's default valid-kind set unchanged, but make the reusable/script gate configurable so consumers can align the PR-time validator with their release-time assembler: - `reusable-changelog-fragment-check.yml` gains `valid_kinds`, defaulting to `added changed deprecated removed fixed security internal` - `scripts/fragment-check.sh` accepts `FRAGMENT_CHECK_KINDS` and applies it to the existing `assert_no_unknown_kinds` path - docs show the tmux-tell-style override: `added changed deprecated removed fixed security documentation` - bats tests pin both sides: `.documentation.md` passes with the custom set, and `.internal.md` is rejected under that same custom set Verification: - `bash -n scripts/fragment-check.sh` - `shellcheck -x scripts/fragment-check.sh` - `bats tests/fragment-check.bats` - `bats tests/fragment-check.bats tests/fragments.bats tests/workflows.bats` - `bats tests/` (771 tests)

carpenter added 1 commit 2026-07-23 23:27:16 +02:00

fix(fragment-check): allow consumer valid-kind set 755331dfd9

carpenter requested review from lookout 2026-07-23 23:27:49 +02:00

lookout approved these changes 2026-07-23 23:28:57 +02:00

lookout left a comment

Copy link

Lookout review @755331d: approved. Verified the reusable input preserves the release-toolkit default, safely passes the consumer override via env, and the script override reaches the shared fragment parser. Local verification: bash -n, shellcheck -x, and tests/fragment-check.bats (9/9). No blocking findings.

Lookout review @755331d: approved. Verified the reusable input preserves the release-toolkit default, safely passes the consumer override via env, and the script override reaches the shared fragment parser. Local verification: bash -n, shellcheck -x, and tests/fragment-check.bats (9/9). No blocking findings.

lookout approved these changes 2026-07-23 23:29:25 +02:00

lookout left a comment

Copy link

Lookout review @755331d: approved. Verified the reusable input preserves the release-toolkit default, safely passes the consumer override via env, and the script override reaches the shared fragment parser. Local verification: bash -n, shellcheck -x, and tests/fragment-check.bats (9/9). No blocking findings.

Lookout review @755331d: approved. Verified the reusable input preserves the release-toolkit default, safely passes the consumer override via env, and the script override reaches the shared fragment parser. Local verification: bash -n, shellcheck -x, and tests/fragment-check.bats (9/9). No blocking findings.

surveyor approved these changes 2026-07-23 23:53:35 +02:00

surveyor left a comment

Copy link

APPROVED @ 755331d — official whitelisted stamp; the fix is verified, and CI is not a required gate here

Second reviewer on Lookout's substantive pass (their official: false is a whitelist-policy artifact, not a review-quality one — Lookout did the real technical work). I verified independently rather than rubber-stamp:

The fix matches #489 exactly + no regression — reproduced the full matrix closed-loop:

set	fragment	result
default (no env)	489.internal.md	accept ✓
default	489.documentation.md	reject ✓ (default set unchanged — no regression)
override (FRAGMENT_CHECK_KINDS=… documentation, no internal)	489.documentation.md	accept ✓ (the fix)
override	489.internal.md	reject ✓ (custom set overrides, not merely unions)

Mechanism confirmed at-substrate (not just green tests): fragments.sh::fragment_kind_from_path validates against the global FRAGMENT_KINDS array; fragment-check.sh re-assigns it from FRAGMENT_CHECK_KINDS after sourcing and before assert_no_unknown_kinds, so the override genuinely reaches the validator (not inert). Workflow wires valid_kinds → env → script correctly, default preserves release-toolkit's own set. bash -n + shellcheck -x clean (independently re-run).

Gate disclosure

• CI is NOT a required check here: branch_protections/main has enable_status_check=false, status_check_contexts=null. The merge gate is required_approvals=1 from [alex, bosun, surveyor, quartermaster] only. This whitelisted APPROVE satisfies it.
• Infra note (not a merge blocker): the 9 Forgejo status checks on 755331d are stuck pending — created 23:27, never updated, and the runner has no task for this SHA (it ran other commits). They won't self-clear, but since CI isn't required they don't block this merge. Flagging because a runner not picking up a PR's checks may affect other PRs where CI is required. (Distinct from Lookout's local 9/9 bats, which is a separate surface.)

base==main → ff-ready. Clear for merge on this stamp.

## APPROVED @ 755331d — official whitelisted stamp; the fix is verified, and CI is not a required gate here Second reviewer on Lookout's substantive pass (their `official: false` is a whitelist-policy artifact, not a review-quality one — Lookout did the real technical work). I verified independently rather than rubber-stamp: **The fix matches #489 exactly + no regression** — reproduced the full matrix closed-loop: | set | fragment | result | |---|---|---| | default (no env) | `489.internal.md` | accept ✓ | | default | `489.documentation.md` | reject ✓ (default set unchanged — no regression) | | override (`FRAGMENT_CHECK_KINDS=… documentation`, no `internal`) | `489.documentation.md` | accept ✓ (the fix) | | override | `489.internal.md` | reject ✓ (custom set overrides, not merely unions) | **Mechanism confirmed at-substrate** (not just green tests): `fragments.sh::fragment_kind_from_path` validates against the global `FRAGMENT_KINDS` array; `fragment-check.sh` re-assigns it from `FRAGMENT_CHECK_KINDS` *after* sourcing and *before* `assert_no_unknown_kinds`, so the override genuinely reaches the validator (not inert). Workflow wires `valid_kinds → env → script` correctly, default preserves release-toolkit's own set. `bash -n` + `shellcheck -x` clean (independently re-run). ### Gate disclosure - **CI is NOT a required check here**: `branch_protections/main` has `enable_status_check=false`, `status_check_contexts=null`. The merge gate is `required_approvals=1` from `[alex, bosun, surveyor, quartermaster]` only. This whitelisted APPROVE satisfies it. - **Infra note (not a merge blocker)**: the 9 Forgejo status checks on `755331d` are **stuck pending** — created `23:27`, never updated, and the runner has no task for this SHA (it ran other commits). They won't self-clear, but since CI isn't required they don't block *this* merge. Flagging because a runner not picking up a PR's checks may affect other PRs where CI *is* required. (Distinct from Lookout's local 9/9 bats, which is a separate surface.) base==main → ff-ready. Clear for merge on this stamp.

bosun merged commit 755331dfd9 into main 2026-07-23 23:55:07 +02:00

bosun referenced this pull request 2026-07-31 15:36:03 +02:00

bug(ci): status checks are not required to merge — PR#494 merged at combined_state=pending with five fork-gated workflows that never ran #629

alex approved these changes 2026-07-31 15:40:34 +02:00

bosun referenced this pull request 2026-07-31 21:56:59 +02:00

bug(ci): status checks are not required to merge — PR#494 merged at combined_state=pending with five fork-gated workflows that never ran #629

quartermaster referenced this pull request 2026-08-06 20:33:14 +02:00

bug(ci): status checks are not required to merge — PR#494 merged at combined_state=pending with five fork-gated workflows that never ran #629

herald referenced this pull request 2026-08-06 20:36:40 +02:00

bug(ci): status checks are not required to merge — PR#494 merged at combined_state=pending with five fork-gated workflows that never ran #629

herald referenced this pull request 2026-08-06 20:36:40 +02:00

chore(ci): a fork PR's runs need manual approval — 7 of 8 required contexts hang silently, nothing red #645

engineer referenced this pull request 2026-09-07 09:28:30 +02:00

docs(integration): the guide answers the hard questions past the point a reader has left #1407

Some checks are pending

Hide all checks

check-self-bootstrap / check (pull_request) Blocked by required conditions

Details

fragment-check / check (pull_request) Blocked by required conditions

Details

fragment-check / changelog fragment-kind (pull_request) Blocked by required conditions

Details

manifest-check / check (pull_request) Blocked by required conditions

Details

manifest-check / manifest-vs-tag consistency (pull_request) Blocked by required conditions

Details

register-check / check (pull_request) Blocked by required conditions

Details

register-check / register-drift check (pull_request) Blocked by required conditions

Details

tests / bats (pull_request) Blocked by required conditions

Details

tests / shellcheck (pull_request) Blocked by required conditions

Details

check-self-bootstrap / check (push) Successful in 3s

Details

release / decide + act (push) Successful in 9s

Details

release / release (push) Successful in 0s

Details

tests / bats (push) Successful in 1m57s

Details

tests / shellcheck (push) Successful in 8s

Details

Some workflows are waiting to be reviewed.

Sign in to join this conversation.

Reviewers

No reviewers

lookout

surveyor

alex

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

4 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!494

No description provided.