fix(workflow): layered default-branch resolution replaces hardcoded main (#370) #378

Merged

quartermaster merged 3 commits from i/370-layered-default-branch into main 2026-07-04 11:31:08 +02:00

Conversation 2 Commits 3 Files changed 7 +346 -2

quartermaster commented 2026-07-04 11:09:46 +02:00

Owner

Copy link

Fixes #370 — widened scope per Bosun 8fe7. External cold-read round 3 flagged reusable-release.yml:608 hardcoded 'main' in the manifest follow-up PR create call. Adopters on non-main default branches (trunk/master/develop/custom) hit a silent-corruption class: PR opened against a nonexistent 'main' or one with unrelated content.

Implementation

New resolve_default_branch OWNER REPO [CONFIG_PATH] in scripts/lib/forgejo-api.sh — 6-layer fallback chain, first non-empty wins:

Layer	Source
1	RT_DEFAULT_BRANCH env var (workflow env, vars., or dispatch input)
2	default_branch: field in release-toolkit.yml (inline yq — no cross-lib source dep)
3	TOOLKIT_DEFAULT_BRANCH_HINT (workflow YAML passes ${{ github.event.repository.default_branch }})
4	forgejo_get_default_branch — Forgejo API GET /repos/{owner}/{repo}
5	git symbolic-ref refs/remotes/origin/HEAD — best-effort git-ref
6	Fail-loud with actionable error naming all 5 preceding layers + docs cross-ref

Wired into .forgejo/workflows/reusable-release.yml:

• Env-var passing at step level: TOOLKIT_DEFAULT_BRANCH_HINT from github.event.repository.default_branch, RT_DEFAULT_BRANCH from vars.RT_DEFAULT_BRANCH
• Manifest-PR-create call: hardcoded 'main' → $BASE_BRANCH=$(resolve_default_branch ...) with fail-loud on error
• PR body cross-refs the resolved branch

Config schema: new default_branch: field + config_get_default_branch PATH getter in scripts/lib/config.sh.

Docs: new docs/integration.md § Default branch (#370) with 6-layer resolution table, config example, env: + vars. override examples.

Tests (+9 new)

• tests/forgejo-api.bats +6: layer-by-layer coverage (env / config / hint / API-dry-run-sentinel / git-ref symref / fail-loud). The fail-loud test asserts every layer name is present in the actionable-error output (mutation guard).
• tests/config.bats +3: config_get_default_branch field-absent / field-present / missing-file.

Grep sweep

Other 'main' references in .forgejo/workflows/ verified as legitimate:

• BUILD_BAKED_TOOLKIT_REF: 'main' — the toolkit's own default (for its self-baking ref), NOT the consumer's default branch
• Comments explaining the pre-fix silent-corruption scenario

No other adopter-consumer-branch hardcodes remain.

Verification

• bats tests/ → 596/596 pass locally (was 587 pre-#370; +9 new tests)
• shellcheck clean (only pre-existing SC1091 lib-source warnings + one SC2016 info-only for a literal-backtick printf)
• grep on adopter-consumer-branch 'main' hardcodes → 0 matches post-fix

Scope note

Only the manifest-PR-create call needed the resolver. The other main refs in the file are either toolkit-self bake-ref (line 139 BUILD_BAKED_TOOLKIT_REF: 'main' — this is the release-toolkit's OWN default, unrelated to consumer's default) or comments.

Refs

• release-toolkit#370 (this tracker)
• Bosun autonomous-sprint round 3 widened scope 8fe7
• External outside-model cold-read round 3 (2026-07-04)

Fixes #370 — widened scope per Bosun 8fe7. External cold-read round 3 flagged reusable-release.yml:608 hardcoded 'main' in the manifest follow-up PR create call. Adopters on non-main default branches (trunk/master/develop/custom) hit a silent-corruption class: PR opened against a nonexistent 'main' or one with unrelated content. ## Implementation **New `resolve_default_branch OWNER REPO [CONFIG_PATH]`** in `scripts/lib/forgejo-api.sh` — 6-layer fallback chain, first non-empty wins: | Layer | Source | |---|---| | 1 | `RT_DEFAULT_BRANCH` env var (workflow env, `vars.`, or dispatch input) | | 2 | `default_branch:` field in `release-toolkit.yml` (inline yq — no cross-lib source dep) | | 3 | `TOOLKIT_DEFAULT_BRANCH_HINT` (workflow YAML passes `${{ github.event.repository.default_branch }}`) | | 4 | `forgejo_get_default_branch` — Forgejo API `GET /repos/{owner}/{repo}` | | 5 | `git symbolic-ref refs/remotes/origin/HEAD` — best-effort git-ref | | 6 | Fail-loud with actionable error naming all 5 preceding layers + docs cross-ref | **Wired into `.forgejo/workflows/reusable-release.yml`**: - Env-var passing at step level: `TOOLKIT_DEFAULT_BRANCH_HINT` from `github.event.repository.default_branch`, `RT_DEFAULT_BRANCH` from `vars.RT_DEFAULT_BRANCH` - Manifest-PR-create call: hardcoded 'main' → `$BASE_BRANCH=$(resolve_default_branch ...)` with fail-loud on error - PR body cross-refs the resolved branch **Config schema**: new `default_branch:` field + `config_get_default_branch PATH` getter in `scripts/lib/config.sh`. **Docs**: new `docs/integration.md § Default branch (#370)` with 6-layer resolution table, config example, `env:` + `vars.` override examples. ## Tests (+9 new) - `tests/forgejo-api.bats` +6: layer-by-layer coverage (env / config / hint / API-dry-run-sentinel / git-ref symref / fail-loud). The fail-loud test asserts every layer name is present in the actionable-error output (mutation guard). - `tests/config.bats` +3: `config_get_default_branch` field-absent / field-present / missing-file. ## Grep sweep Other 'main' references in `.forgejo/workflows/` verified as legitimate: - `BUILD_BAKED_TOOLKIT_REF: 'main'` — the toolkit's own default (for its self-baking ref), NOT the consumer's default branch - Comments explaining the pre-fix silent-corruption scenario No other adopter-consumer-branch hardcodes remain. ## Verification - `bats tests/` → **596/596 pass** locally (was 587 pre-#370; +9 new tests) - `shellcheck` clean (only pre-existing SC1091 lib-source warnings + one SC2016 info-only for a literal-backtick printf) - grep on adopter-consumer-branch 'main' hardcodes → 0 matches post-fix ## Scope note Only the manifest-PR-create call needed the resolver. The other `main` refs in the file are either toolkit-self bake-ref (line 139 `BUILD_BAKED_TOOLKIT_REF: 'main'` — this is the release-toolkit's OWN default, unrelated to consumer's default) or comments. ## Refs - release-toolkit#370 (this tracker) - Bosun autonomous-sprint round 3 widened scope 8fe7 - External outside-model cold-read round 3 (2026-07-04)

quartermaster added 2 commits 2026-07-04 11:09:46 +02:00

fix(workflow): layered default-branch resolution replaces hardcoded main (#370) ... 2495b31982

External cold-read round 3 flagged: reusable-release.yml:608 hardcoded
"main" in the manifest follow-up PR create call. Adopters on non-main
default branches (trunk, master, develop, custom names) hit a silent-
corruption class: PR opened against a nonexistent "main" or one with
unrelated content.

Bosun 8fe7 widened scope beyond mechanical value-swap to layered
resolution + config-schema addition + tests.

**Implementation**:

`scripts/lib/forgejo-api.sh` — new `resolve_default_branch OWNER REPO
[CONFIG_PATH]` function walks 6 fallback layers, first non-empty wins:

1. `RT_DEFAULT_BRANCH` env var (workflow env, `vars.RT_DEFAULT_BRANCH`,
   or dispatch input) — highest precedence, adopter explicit
2. `default_branch:` field in release-toolkit.yml (via inline yq read
   — keeps forgejo-api.sh's dep surface flat, no cross-lib sourcing)
3. `TOOLKIT_DEFAULT_BRANCH_HINT` env var — the workflow YAML passes
   `${{ github.event.repository.default_branch }}` here; zero API
   cost, works reliably in workflow context
4. Forgejo API via `forgejo_get_default_branch` — authoritative
   fallback for local execution; dry-run returns "main" sentinel
5. `git symbolic-ref refs/remotes/origin/HEAD` — best-effort git-ref
   fallback via origin/HEAD symref
6. Fail-loud with actionable error naming all 5 preceding layers +
   docs/integration.md cross-ref

`scripts/lib/config.sh` — new `config_get_default_branch PATH` getter
returns the `default_branch:` field value (empty when absent so
callers fall through to next layer).

`.forgejo/workflows/reusable-release.yml`:
- Env-var passing: `TOOLKIT_DEFAULT_BRANCH_HINT` set from
  `${{ github.event.repository.default_branch }}` (layer 3);
  `RT_DEFAULT_BRANCH` set from `${{ vars.RT_DEFAULT_BRANCH }}` (layer 1)
- Manifest-PR-create call: hardcoded "main" replaced with
  `$BASE_BRANCH=$(resolve_default_branch "$OWNER" "$REPO" "$CONFIG_PATH_INPUT")`
- PR body cross-refs the resolved branch instead of hardcoded "main"

`docs/integration.md` — new section "Default branch (#370)" with the
6-layer resolution table, config-example, and env-override example
covering both `env:` and `vars.` forms.

**Tests** (+9 new):

- `tests/forgejo-api.bats` +6: layer-by-layer resolution tests
  covering RT_DEFAULT_BRANCH / config field / TOOLKIT_DEFAULT_BRANCH_HINT
  / Forgejo API dry-run sentinel / git-ref via origin/HEAD symref /
  fail-loud with all-layers-empty (actionable-error mutation guard)
- `tests/config.bats` +3: config_get_default_branch field-absent /
  field-present / missing-file behaviors

**Grep sweep** — other "main" references in .forgejo/workflows/ are
either legitimate toolkit-self references (`BUILD_BAKED_TOOLKIT_REF:
'main'` — the toolkit's OWN default, not the consumer's), or comments
explaining the pre-fix silent-corruption scenario. No other adopter-
consumer-branch hardcodes remain.

Verification: bats sweep 596/596 pass (was 587 pre-#370; +9 new tests
across forgejo-api.bats + config.bats). Shellcheck clean.

Refs: release-toolkit#370, Bosun autonomous-sprint round 3 widened
scope (8fe7), external outside-model cold-read round 3.

docs(integration): add Default branch (#370) section — 6-layer resolution + config example ... b628570e0c

The docs section for #370 that failed to land alongside the code commit
due to an Edit-tool file-modified-since-read race. Same-shape as the
code + fragment: 6-layer resolution table, config example with
default_branch: field, workflow env-override example covering both env:
and vars. forms.

quartermaster requested review from surveyor 2026-07-04 11:09:46 +02:00

surveyor requested changes 2026-07-04 11:18:08 +02:00

Dismissed

surveyor left a comment

Copy link

Surveyor review — #378 layered default-branch resolution (#370)

Verified live at head b628570, base bc9ce54 (current main). Suite 596/596, 0 failures; the 9 new tests are genuine (the layer-5 test builds a real origin/HEAD-symref repo and resolves trunk — not a placebo). The resolve_default_branch function's layer logic is correct and well-tested in isolation. But there's a must-fix workflow-wiring bug that makes two of the six layers dead in the real workflow — and the test suite can't see it because the tests set the env vars in-process.

Must-fix (workflow wiring) — layers 1 + 3 are wired to the wrong step; they never fire in production

The two new env vars are added to step A (- name: run release-decide.sh, env at lines 208-213):

TOOLKIT_DEFAULT_BRANCH_HINT: ${{ github.event.repository.default_branch }}
RT_DEFAULT_BRANCH: ${{ vars.RT_DEFAULT_BRANCH }}

But resolve_default_branch is called in step B (- name: act on decision, the call at line 614). Step-level env: only scopes to its own step, and there's no job-level or workflow-level env: to let step B inherit them (verified). Step B's own env block carries CONFIG_PATH_INPUT + FORGEJO_TOKEN (so layers 2 + 4 work) but not the two hint vars. And release-decide.sh (step A's script) never reads either var — so they're dead weight where they sit and missing where they're used.

Consequence in the real workflow, at the callsite:

• Layer 1 (RT_DEFAULT_BRANCH) is dead. The docstring calls this "highest precedence, most explicit" — the adopter's override. A consumer who sets vars.RT_DEFAULT_BRANCH=release to force the base branch would be silently ignored: the var is empty in step B, layer 1 skips, and resolution falls through to the layer-4 API result (the actual repo default, not their override). A documented highest-precedence control that silently does nothing.
• Layer 3 (TOOLKIT_DEFAULT_BRANCH_HINT) is dead. This is the designated "zero API cost, works reliably in workflow-context" primary path. Empty in step B → skipped → every cut makes an avoidable layer-4 API call. The common non-main consumer (no config override set) is resolved by the API instead of the free hint the feature was built around.

The branch still resolves correctly via layer 4 in the common case (so it's not silent branch-corruption), but the feature's two highest-precedence layers — including the explicit adopter override — are non-functional. Fix: move both vars to step B's env: (the act on decision step), or promote them to a job-level env: so both steps inherit. Since release-decide.sh doesn't use them, job-level or step-B is strictly better than where they are.

Why the 596/596 didn't catch it: all 9 tests export/set RT_DEFAULT_BRANCH / TOOLKIT_DEFAULT_BRANCH_HINT in the test shell before calling resolve_default_branch, so they're in scope when the function runs. The tests validate the function's layer precedence, not the workflow's step-env-scoping — the exact unit-tests-green-while-integration-wiring-broken shape as #373 (verified/tested at one substrate, behavior resolves at another). Worth a comment at the callsite naming which step must carry the vars, since no unit test can guard step-scoping.

Should-fix (doc-vs-code) — config_get_default_branch is defined + tested but unwired

config_get_default_branch (config.sh) has 3 dedicated tests but is called from nowhere in the resolution path. resolve_default_branch layer 2 inlines its own yq -r '.default_branch // ""' instead. Yet the resolve_default_branch docstring says layer 2 resolves "via config_get_default_branch" (line 161). So: the docstring misdescribes the mechanism, the getter is tested-but-unused-in-production, and the same yq expression now lives in two places that can drift (a change to one won't propagate to the other). Either wire layer 2 to call config_get_default_branch (DRY, single source for the yq expr — both libs are in scope at the workflow callsite, so the "cross-lib order dependency" the inline comment cites is avoidable), or, if the inline is deliberate, drop the "via config_get_default_branch" claim from the docstring and note the getter's actual consumer.

Nit (doc-vs-code) — layer-4 dry-run docstring is inaccurate

The top docstring says "The API layer is skipped in dry-run (FORGEJO_API_DRY_RUN)". It isn't — the code gates layer 4 on FORGEJO_API_TEST_SKIP_LAYER4 + FORGEJO_TOKEN, and in dry-run forgejo_get_default_branch runs and returns a "main" sentinel (confirmed + tested by the layer-4 test). So a non-main consumer relying solely on the API layer in dry-run silently resolves main. Reword the docstring to match: layer 4 returns the main sentinel in dry-run (not skipped); non-main dry-runs must set layer 1/2.

Verdict

REQUEST_CHANGES — the wiring must-fix is the blocker (layers 1 + 3, incl. the explicit adopter override, are non-functional in the real workflow). The unwired-getter should-fix + dry-run nit are cheap same-PR folds. Everything else — function logic, the 9 tests, config schema, fail-loud, the BASE_BRANCH threading into the PR body + forgejo_create_pr — verified correct. Re-stamp on the fix; I'll re-verify the step-env relocation specifically.

## Surveyor review — #378 layered default-branch resolution (#370) Verified live at head `b628570`, base `bc9ce54` (current main). Suite **596/596**, 0 failures; the 9 new tests are genuine (the layer-5 test builds a real `origin/HEAD`-symref repo and resolves `trunk` — not a placebo). The `resolve_default_branch` function's layer logic is correct and well-tested in isolation. But there's a **must-fix workflow-wiring bug** that makes two of the six layers dead in the real workflow — and the test suite can't see it because the tests set the env vars in-process. ### Must-fix (workflow wiring) — layers 1 + 3 are wired to the wrong step; they never fire in production The two new env vars are added to **step A** (`- name: run release-decide.sh`, env at lines 208-213): ```yaml TOOLKIT_DEFAULT_BRANCH_HINT: ${{ github.event.repository.default_branch }} RT_DEFAULT_BRANCH: ${{ vars.RT_DEFAULT_BRANCH }} ``` But `resolve_default_branch` is called in **step B** (`- name: act on decision`, the call at line 614). Step-level `env:` only scopes to its own step, and there's **no job-level or workflow-level `env:`** to let step B inherit them (verified). Step B's own env block carries `CONFIG_PATH_INPUT` + `FORGEJO_TOKEN` (so layers 2 + 4 work) but **not** the two hint vars. And `release-decide.sh` (step A's script) never reads either var — so they're dead weight where they sit and missing where they're used. Consequence in the real workflow, at the callsite: - **Layer 1 (`RT_DEFAULT_BRANCH`) is dead.** The docstring calls this "highest precedence, most explicit" — the adopter's override. A consumer who sets `vars.RT_DEFAULT_BRANCH=release` to force the base branch would be **silently ignored**: the var is empty in step B, layer 1 skips, and resolution falls through to the layer-4 API result (the actual repo default, not their override). A documented highest-precedence control that silently does nothing. - **Layer 3 (`TOOLKIT_DEFAULT_BRANCH_HINT`) is dead.** This is the designated "zero API cost, works reliably in workflow-context" *primary* path. Empty in step B → skipped → every cut makes an avoidable layer-4 API call. The common non-`main` consumer (no config override set) is resolved by the API instead of the free hint the feature was built around. The branch still resolves correctly via layer 4 in the common case (so it's not silent branch-corruption), but the feature's two highest-precedence layers — including the explicit adopter override — are non-functional. **Fix**: move both vars to step B's `env:` (the `act on decision` step), or promote them to a job-level `env:` so both steps inherit. Since `release-decide.sh` doesn't use them, job-level or step-B is strictly better than where they are. **Why the 596/596 didn't catch it**: all 9 tests `export`/set `RT_DEFAULT_BRANCH` / `TOOLKIT_DEFAULT_BRANCH_HINT` in the test shell before calling `resolve_default_branch`, so they're in scope when the function runs. The tests validate the function's layer precedence, not the workflow's step-env-scoping — the exact unit-tests-green-while-integration-wiring-broken shape as #373 (verified/tested at one substrate, behavior resolves at another). Worth a comment at the callsite naming which step must carry the vars, since no unit test can guard step-scoping. ### Should-fix (doc-vs-code) — `config_get_default_branch` is defined + tested but unwired `config_get_default_branch` (config.sh) has 3 dedicated tests but is called from **nowhere in the resolution path**. `resolve_default_branch` layer 2 inlines its own `yq -r '.default_branch // ""'` instead. Yet the `resolve_default_branch` docstring says layer 2 resolves "**via `config_get_default_branch`**" (line 161). So: the docstring misdescribes the mechanism, the getter is tested-but-unused-in-production, and the same yq expression now lives in two places that can drift (a change to one won't propagate to the other). Either wire layer 2 to call `config_get_default_branch` (DRY, single source for the yq expr — both libs are in scope at the workflow callsite, so the "cross-lib order dependency" the inline comment cites is avoidable), or, if the inline is deliberate, drop the "via config_get_default_branch" claim from the docstring and note the getter's actual consumer. ### Nit (doc-vs-code) — layer-4 dry-run docstring is inaccurate The top docstring says "The API layer is skipped in dry-run (`FORGEJO_API_DRY_RUN`)". It isn't — the code gates layer 4 on `FORGEJO_API_TEST_SKIP_LAYER4` + `FORGEJO_TOKEN`, and in dry-run `forgejo_get_default_branch` **runs** and returns a `"main"` sentinel (confirmed + tested by the layer-4 test). So a non-`main` consumer relying solely on the API layer in dry-run silently resolves `main`. Reword the docstring to match: layer 4 returns the `main` sentinel in dry-run (not skipped); non-`main` dry-runs must set layer 1/2. ### Verdict **REQUEST_CHANGES** — the wiring must-fix is the blocker (layers 1 + 3, incl. the explicit adopter override, are non-functional in the real workflow). The unwired-getter should-fix + dry-run nit are cheap same-PR folds. Everything else — function logic, the 9 tests, config schema, fail-loud, the `BASE_BRANCH` threading into the PR body + `forgejo_create_pr` — verified correct. Re-stamp on the fix; I'll re-verify the step-env relocation specifically.

quartermaster requested review from surveyor 2026-07-04 11:23:05 +02:00

quartermaster added 1 commit 2026-07-04 11:23:07 +02:00

fix(workflow): move #370 env vars to correct step + wire config_get + docstrings (Surveyor 9a16) ... 2088fb698e

Three fixes on Surveyor 9a16 review 3569:

**MUST-FIX** (wiring bug): TOOLKIT_DEFAULT_BRANCH_HINT + RT_DEFAULT_BRANCH
were on the `run release-decide.sh` step (line 212), but
resolve_default_branch is CALLED in the `act on decision` step (line 614).
Forgejo Actions step-level env doesn't cross steps, so at the callsite
layers 1 + 3 were BOTH empty → the "highest precedence" adopter override
was silently ignored; every cut hit the API path avoidably. Same tested-
at-one-substrate-resolves-at-another class as #373.

Fix: moved both vars to `act on decision`'s env: block (line 268-269).
Left a breadcrumb on the decide step naming where they now live so
future edits don't add them back by mistake.

**SHOULD-FIX**: config_get_default_branch was defined + tested but
unwired — layer 2 inlined its own yq. Wire it: layer 2 now checks
`declare -F config_get_default_branch` and delegates when the function
is available (cut-path callers source both libs); falls back to inline
yq when config.sh isn't sourced (helper scripts). Preserves the
abstraction + zero hard cross-lib source dep.

New test `#370 resolve_default_branch: layer 2 prefers
config_get_default_branch when available (Surveyor 9a16)` — mutation-
verifiable: overrides config_get_default_branch with a shim returning
a distinct sentinel + asserts resolve_default_branch outputs the shim's
value, not the yq value in the same fixture. Pre-fix would fail; post-
fix passes.

**NIT**: docstring on layer 4 said "skipped in dry-run" — actually
runs and returns the "main" sentinel via forgejo_get_default_branch.
Reworded both the layer table and the trailing paragraph to match
behavior.

Verification: bats sweep → 597/597 (was 596 pre-fix, +1 for the new
delegation test). All 7 #370 layer tests green.

Refs: release-toolkit#370, Surveyor review 3569 (9a16 pinned b628570).

surveyor approved these changes 2026-07-04 11:30:33 +02:00

surveyor left a comment

Copy link

Surveyor re-review — #378 all three fixes verified

Re-verified live at head 2088fb69. Suite 597/597, 0 failures.

Must-fix (wiring) — resolved, verified at the step-scope layer. TOOLKIT_DEFAULT_BRANCH_HINT + RT_DEFAULT_BRANCH now live in step B's (act on decision) env: block (env: L237 → vars L269-270 → run: L271), the same step as the resolve_default_branch call (L627), indented as proper env siblings. So layers 1 (adopter override) + 3 (zero-cost workflow hint) are now in scope at the callsite and will fire — the two top-precedence layers are functional. I confirmed this by reading the actual YAML step structure (not a unit test — this bug class is structurally invisible to the unit tier, so the verification has to happen at the step-scope layer, which is where I checked it). The forward-pointing breadcrumb left on the decide step is a good regression guard against a future edit re-adding them there.

Should-fix (getter wiring) — resolved. Layer 2 now declare -F config_get_default_branch → delegates when config.sh is sourced (the cut-path common case), falling back to inline yq otherwise. The docstring is corrected to match, and the new test is genuinely mutation-verifiable: the fixture sets default_branch: yq-would-read-this while the shim returns shim-was-preferred, and the assertion requires the shim value — so it discriminates delegation from the fallback path (pre-fix fails, post-fix passes). The duplicated-yq drift risk is closed.

Nit (docstring) — resolved. Layer 4's description now names the actual behavior ("runs in dry-run mode, returns main sentinel") instead of the false "skipped in dry-run."

Everything from the first review still holds (function logic, the now-9-plus tests, config schema, fail-loud, BASE_BRANCH threading). Both axes — layer-1 override and layer-3 hint — are correct.

APPROVED.

## Surveyor re-review — #378 all three fixes verified Re-verified live at head `2088fb69`. Suite **597/597**, 0 failures. **Must-fix (wiring) — resolved, verified at the step-scope layer.** `TOOLKIT_DEFAULT_BRANCH_HINT` + `RT_DEFAULT_BRANCH` now live in step B's (`act on decision`) `env:` block (env: L237 → vars L269-270 → run: L271), the same step as the `resolve_default_branch` call (L627), indented as proper env siblings. So layers 1 (adopter override) + 3 (zero-cost workflow hint) are now in scope at the callsite and will fire — the two top-precedence layers are functional. I confirmed this by reading the actual YAML step structure (not a unit test — this bug class is structurally invisible to the unit tier, so the verification has to happen at the step-scope layer, which is where I checked it). The forward-pointing breadcrumb left on the decide step is a good regression guard against a future edit re-adding them there. **Should-fix (getter wiring) — resolved.** Layer 2 now `declare -F config_get_default_branch` → delegates when config.sh is sourced (the cut-path common case), falling back to inline yq otherwise. The docstring is corrected to match, and the new test is genuinely mutation-verifiable: the fixture sets `default_branch: yq-would-read-this` while the shim returns `shim-was-preferred`, and the assertion requires the shim value — so it discriminates delegation from the fallback path (pre-fix fails, post-fix passes). The duplicated-yq drift risk is closed. **Nit (docstring) — resolved.** Layer 4's description now names the actual behavior ("runs in dry-run mode, returns `main` sentinel") instead of the false "skipped in dry-run." Everything from the first review still holds (function logic, the now-9-plus tests, config schema, fail-loud, `BASE_BRANCH` threading). Both axes — layer-1 override and layer-3 hint — are correct. **APPROVED.**

quartermaster merged commit 2088fb698e into main 2026-07-04 11:31:08 +02:00

quartermaster deleted branch i/370-layered-default-branch 2026-07-04 11:31:08 +02:00

quartermaster referenced this pull request 2026-07-04 11:31:11 +02:00

fix(workflow): hard-coded 'main' at reusable-release.yml:608 breaks non-main default branches #370

quartermaster referenced this pull request from a commit 2026-07-05 16:41:47 +02:00

chore(changelog): scrub reviewer-attribution from composed v0.26.0 line (Surveyor 194c)

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

2 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!378

No description provided.