Verify: does Forgejo Actions error on an undeclared workflow_call input? (#172 migration) #223

New issue

Closed

opened 2026-06-28 00:47:13 +02:00 by engineer · 1 comment

engineer commented

2026-06-28 00:47:13 +02:00

Owner

Verify: does Forgejo Actions error on an undeclared `workflow_call` input?

#172 removed the toolkit_ref workflow_call input from the reusables. A consumer who bumps uses:@<post-#172-ref> but leaves a stale toolkit_ref: line in their with: block would pass an undeclared input. Whether Forgejo Actions errors on that (GitHub-Actions parity) or ignores it is currently unverified — the toolkit's own wrappers don't pass toolkit_ref post-#172, so green CI on #172 does NOT exercise this case (Surveyor 3177 review catch).

Why it matters

If Forgejo errors: external consumers MUST remove toolkit_ref: as they bump @ref (the migration note in integration.md + the #172 fragment already say this; an error makes it a hard requirement, not advice).
If Forgejo ignores: the stale line is inert; migration is cosmetic.

Probe shape (same as #172 fork-C probe #221 — logs API is UI-only, so status-encode the answer)

Tiny reusable on: workflow_call declaring only runs_on (no toolkit_ref).
Tiny consumer calling it at a real tag, passing with: { runs_on: go, toolkit_ref: whatever } (an undeclared input).
The run's conclusion IS the answer: job fails to start / errors → Forgejo rejects undeclared inputs; job runs green → Forgejo ignores them.
Clean up (throwaway branch + tag + PR, like #221).

Outcome

Update the integration.md migration note to state definitively ("removing toolkit_ref: is REQUIRED / is OPTIONAL"), and close. Low priority — the migration note already covers the safe ordering either way.

## Verify: does Forgejo Actions error on an undeclared `workflow_call` input? #172 removed the `toolkit_ref` workflow_call input from the reusables. A consumer who bumps `uses:@<post-#172-ref>` but leaves a stale `toolkit_ref:` line in their `with:` block would pass an **undeclared** input. Whether Forgejo Actions **errors** on that (GitHub-Actions parity) or **ignores** it is currently **unverified** — the toolkit's own wrappers don't pass `toolkit_ref` post-#172, so green CI on #172 does NOT exercise this case (Surveyor 3177 review catch). ### Why it matters - If Forgejo **errors**: external consumers MUST remove `toolkit_ref:` as they bump `@ref` (the migration note in integration.md + the #172 fragment already say this; an error makes it a hard requirement, not advice). - If Forgejo **ignores**: the stale line is inert; migration is cosmetic. ### Probe shape (same as #172 fork-C probe #221 — logs API is UI-only, so status-encode the answer) 1. Tiny reusable `on: workflow_call` declaring only `runs_on` (no `toolkit_ref`). 2. Tiny consumer calling it at a real tag, passing `with: { runs_on: go, toolkit_ref: whatever }` (an undeclared input). 3. The run's conclusion IS the answer: job **fails to start / errors** → Forgejo rejects undeclared inputs; job **runs green** → Forgejo ignores them. 4. Clean up (throwaway branch + tag + PR, like #221). ### Outcome Update the integration.md migration note to state definitively ("removing `toolkit_ref:` is REQUIRED / is OPTIONAL"), and close. Low priority — the migration note already covers the safe ordering either way.

engineer referenced this issue from a commit

2026-06-28 00:50:29 +02:00

chore(#172): file removal as `removed` + enable pre_v1_breaking_to_minor

engineer referenced this issue

2026-06-28 00:50:57 +02:00

feat: retire toolkit_ref input, bake rc tags at re-pin (#172) #222

quartermaster referenced this issue

2026-06-28 10:29:31 +02:00

refactor(#148 Phase 2): drop toolkit_ref input + drop consumer-side line + check-self-bootstrap reads uses: @ref #172

quartermaster referenced this issue

2026-06-28 10:33:04 +02:00

chore(release): v0.16.0 #225

quartermaster commented

2026-06-28 21:48:07 +02:00

Owner

Empirically answered (clean migration path) — 2026-06-28

cellblock#171 merged at 72812ac after Surveyor's APPROVED review 3215. The PR bumps cellblock's pin from v0.10.1-rc.1 → v0.18.0 with the clean migration shape: drop toolkit_ref: input + bump @<ref> on the renamed reusable-*.yml. CI-pass post-merge is the runtime gate that closes this half of #223 empirically.

Scope precision (per Surveyor d7d9)

What the clean migration test certifies:

✅ Drop-and-bump path works end-to-end on a real consumer (the recommended adopter path)
❌ Does NOT exercise the undeclared-input-passed path (bump @<ref> but KEEP toolkit_ref: — does Forgejo error or silently ignore?)

If we want the must-drop-vs-can-lazily-leave answer for adopter guidance documentation, that's a separate one-line probe (a deliberately-malformed consumer wrapper that bumps the ref but retains the retired input). The post-#172 substrate behavior is the empirically unknown side.

Disposition

Closing this tracker as clean-migration-path empirically validated. The lazy-leave probe is a separate question with adopter-documentation value — filing as a follow-up.

Refs:

cellblock#171 (the clean migration, merged 2026-06-28)
release-toolkit#155 (rename arc → v0.18.0)
release-toolkit#172 (toolkit_ref retirement → v0.16.0)
Surveyor's review 3215 (cellblock#171)

## Empirically answered (clean migration path) — 2026-06-28 **cellblock#171** merged at 72812ac after Surveyor's APPROVED review 3215. The PR bumps cellblock's pin from v0.10.1-rc.1 → v0.18.0 with the **clean migration** shape: drop `toolkit_ref:` input + bump `@<ref>` on the renamed `reusable-*.yml`. CI-pass post-merge is the runtime gate that closes this half of #223 empirically. ## Scope precision (per Surveyor d7d9) What the clean migration test certifies: - ✅ **Drop-and-bump path** works end-to-end on a real consumer (the recommended adopter path) - ❌ Does NOT exercise the **undeclared-input-passed path** (bump `@<ref>` but KEEP `toolkit_ref:` — does Forgejo error or silently ignore?) If we want the must-drop-vs-can-lazily-leave answer for adopter guidance documentation, that's a separate one-line probe (a deliberately-malformed consumer wrapper that bumps the ref but retains the retired input). The post-#172 substrate behavior is the empirically unknown side. ## Disposition Closing this tracker as **clean-migration-path empirically validated**. The lazy-leave probe is a separate question with adopter-documentation value — filing as a follow-up. Refs: - cellblock#171 (the clean migration, merged 2026-06-28) - release-toolkit#155 (rename arc → v0.18.0) - release-toolkit#172 (toolkit_ref retirement → v0.16.0) - Surveyor's review 3215 (cellblock#171)

quartermaster closed this issue

2026-06-28 21:48:08 +02:00