feat(examples): populate examples/go-project and examples/node-project with drop-in consumer setups #152
Labels
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
No milestone
No project
No assignees
1 participant
herald
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#152
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The current state
The
examples/directory has two subdirectories that were scaffolded in the initial commit but never populated:examples/go-project/.keepexamples/node-project/.keepBoth contain ONLY a
.keepfile. Surfaced during the pre-1.0 audit pass 2026-06-27.The substantive value (per operator framing 2026-06-27)
Examples would serve as copy-pasteable starting points for new consumers: clone the example, rename, adjust 2-3 things, and you have a working release-toolkit-driven repo. Onboarding value is concrete — currently consumers must read
docs/integration.md+ assemble the pieces by hand from text descriptions.What each example would contain
Each project would be a minimal working consumer setup:
README.mdrelease-toolkit.ymlCHANGELOG.md## [Unreleased]sectionchangelog.d/.keep.forgejo/workflows/release.ymlpaths-ignore+secrets: inherit+publish_mode: immediatedefaults.forgejo/workflows/manifest-check.ymlpackage.json(node) /VERSION+go.mod(go)Total per example: 6-7 files of consumer-side content. Both examples combined: ~14 files / ~250 lines.
Why probing was worth it (vars + ref discoveries)
The 2026-06-27 probes for variabilizing the consumer wrapper produced these findings:
uses: ${{ vars.X }}does NOT work in Forgejo Actions (HTTP 500 on dispatch; theuses:clause requires a compile-time literal). The@<ref>line must stay literal.github.workflow_refin a reusable points at the CALLER, not the reusable. So the reusable can't self-discover its own ref via context vars. (Documented in #148.)vars.Xin workflow_call has timing quirks — value reads showed cached/stale values in dispatched runs. Vars work but the reliability is unclear; not worth the cognitive load for runner-label selection. Keepruns_onas an explicit input.Two paths forward for the examples shape
The examples' consumer wrapper shape depends on #148 (build-bake
toolkit_refelimination) resolution:| If #148 ships first | Examples use the simpler schema |
uses: ...@vX.Y.Z+runs_on: goonly || If #148 deferred or rejected | Examples use current schema |
uses: ...@vX.Y.Z+toolkit_ref: vX.Y.Z(literal duplication) +runs_on: go|Recommended sequencing: ship #148 first → then ship this examples sprint with the cleaner schema. Avoids reworking the examples post-#148.
Implementation surface
examples/go-project/: 6-7 files (drop.keep)examples/node-project/: 6-7 files (drop.keep)docs/integration.md: link to the examples from the quick-startEstimated scope: ~250 lines + 1 PR cycle.
What this PR does NOT do
node+go+multi+pythontypes are sufficientComposition
examples/*/.keepretirement — when examples get populated, the.keepfiles become redundant + can be dropped in the same PR.Refs
uses: vars.Ximpossible,github.workflow_refshows caller's ref,vars.Xtiming quirks (captured in #148)toolkit_refrefactor — sequenced before this), #151 (.keepcleanup — bundled-with-this PR likely)