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

Document host-native release launchers

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-04 00:54:44 +00:00
parent bd693ca31b
commit 0269648429
6 changed files with 40 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/consumers/adoption.md
View File

@@ -12,7 +12,6 @@ From the consumer module's root, select the ReleaseKit version to adopt:
: "${RELEASEKIT_TOOL_VERSION:?Set the released ReleaseKit version to adopt}"
go get -tool "go.maximumdirect.net/releasekit/cmd/releasekit@${RELEASEKIT_TOOL_VERSION}"
go mod tidy
go tool releasekit version
```
Select a release that implements the API, profile, and workflow you are adopting.
@@ -39,9 +38,15 @@ A launcher invoked from that module 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 "$@"
```
Save this launcher as `releasekit` and run `./releasekit version` from the
selected module to verify registration. It preserves the consumer's workspace
and toolchain settings while selecting the host for the executable.
For a launcher callable from other directories, first change to its consumer
module directory. Follow the [CLI contract](../cli.md) for commands and exit
statuses, and the [configuration reference](../config.md) for the release profile.
@@ -108,6 +113,10 @@ selection, 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.
Update copied launchers and workflow templates separately when upgrading the
module dependency. ReleaseKit tests the generic bootstrap; consumer wiring tests
can focus on selectors and profile mapping. Profiles continue to select
application build targets.
Upgrade the module-selected tool and workflow together. For a tag created before
that upgrade, retry with the workflow matching the tool recorded at that tag.
Keep its immutable module files and tag intact. See the

3
docs/consumers/delivery.md
View File

@@ -293,7 +293,8 @@ identify an annotated tag object or a commit. The template requires the resolved
commits to match, checks out that commit detached, and confirms the source tree
is clean. It then copies the tagged `go.mod` and any `go.sum` to a temporary
directory outside the checkout. `go list -m` confirms that the module selects
ReleaseKit. The template adds its CLI tool declaration to that temporary copy
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