base-layer/releasekit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 5 Wiki Activity

Invoke the registered ReleaseKit package explicitly

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-04 01:51:36 +00:00
parent f625674a68
commit bd1c714935
10 changed files with 43 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/cli.md
View File

@@ -342,11 +342,12 @@ status 2. Final delivery uses the same statuses as `deliver`: 0 for complete,
state, including when cancellation prevents reconciliation.
The maintained module-based tag workflow verifies and checks out the event tag
before resolving the consumer module. It runs `go tool releasekit` for the version
already selected by that tagged `go.mod`, using temporary alternate module files
outside the source checkout. This tool bootstrap is separate from `ci-deliver`'s
application dependency preparation for binary profiles. ReleaseKit's own
source workflow self-bootstraps `./cmd/releasekit`; consumers without a declared
before resolving the consumer module. It invokes the ReleaseKit tool by its full
package path for the version already selected by that tagged `go.mod`, using
temporary alternate module files outside the source checkout. This tool bootstrap
is separate from `ci-deliver`'s application dependency preparation for binary
profiles. ReleaseKit's own source workflow self-bootstraps `./cmd/releasekit`;
consumers without a declared
ReleaseKit module dependency can use the separately installed-tool command.
See the [delivery guide](consumers/delivery.md#woodpecker-tag-workflows) for
compatible Go environments, retries, and preparation details.

15
docs/consumers/adoption.md
View File

@@ -34,16 +34,17 @@ Go minimum. See the
### Select the Go host target
Run `go tool releasekit` from within the consumer module to use its selected
version. Go builds and caches the executable and preserves its exit status.
A launcher invoked from that module can forward commands directly:
Invoke the ReleaseKit tool by its full package path from within the consumer
module to use its selected version. Go builds and caches the executable and
preserves its exit status. The full path distinguishes tools with the same
short name. A launcher can forward commands directly:
```sh
#!/bin/sh
releasekit_host_os=$(go env GOHOSTOS) || exit $?
releasekit_host_arch=$(go env GOHOSTARCH) || exit $?
export GOOS="$releasekit_host_os" GOARCH="$releasekit_host_arch"
exec go tool releasekit "$@"
exec go tool go.maximumdirect.net/releasekit/cmd/releasekit "$@"
```
Save this launcher as `releasekit` and run `sh ./releasekit version` from the
@@ -114,9 +115,9 @@ Go module identity. The Go consumer minimum remains 1.26.0.
## CI adoption
The maintained [consumer tag-delivery workflow](delivery.md#woodpecker-tag-workflows)
supports both tool and ordinary package dependencies. It runs `go tool releasekit`
with temporary module metadata derived from the tagged consumer's module
selection, so the committed module files also govern CI delivery and retries.
supports both tool and ordinary package dependencies. It runs the ReleaseKit
tool by its full package path with temporary metadata derived from the tagged
module, so the committed module files also govern CI delivery and retries.
Registering the CLI as a tool is sufficient for
consumers that use ReleaseKit only for maintainer commands.

7
docs/consumers/delivery.md
View File

@@ -296,9 +296,10 @@ directory outside the checkout. `go list -m` confirms that the module selects
ReleaseKit. The template selects the host Go target before preparing and running
the CLI. The template adds its CLI tool declaration to that temporary copy
and prepares tool dependencies with `go list -deps`. It then uses
`go tool -modfile=... releasekit` to build, cache, and run the selected tool with
`CI_WORKSPACE`, the resolved event commit, and `CI_COMMIT_TAG`. The tagged module
files stay unchanged, including for consumers with an ordinary package
`go tool -modfile=... go.maximumdirect.net/releasekit/cmd/releasekit` to build,
cache, and run the selected tool with `CI_WORKSPACE`, the resolved event commit,
and `CI_COMMIT_TAG`. The tagged module files stay unchanged, including for
consumers with an ordinary package
dependency. A cleanup trap removes the temporary metadata; Go manages the
cached executable. The command preserves the tool's exit status.

4
docs/roadmap/remediation.md
View File

@@ -235,6 +235,10 @@ once. No additional scaling issue was identified.
### Stages 1, 2, and 6: Invoke the exact registered Go tool
**Completed.** The launchers, templates, and consumer recipes use the full
package path. The real Go launcher regression verifies tool selection and
exit statuses with a second registered tool of the same short name.
**Evidence:** The [multi-module launcher](../../examples/multi-module/release.sh)
and both consumer Woodpecker templates
([single-module](../../examples/woodpecker/tag-delivery.yml),