94 lines
4.5 KiB
Markdown
94 lines
4.5 KiB
Markdown
# CommandKit feature request: host-safe consumer launchers
|
|
|
|
Status: proposed; not an accepted contract or implementation assignment.
|
|
|
|
## Consumer need
|
|
|
|
CommandKit selects ReleaseKit v0.8.0 as a Go tool and uses a small launcher to
|
|
publish its core and two optional integration modules. Maintainers can inherit
|
|
`GOOS` and `GOARCH` from application cross-build work. The release tool must run
|
|
on the maintainer's host even when those variables name another target.
|
|
|
|
CommandKit currently handles this by querying `go env GOHOSTOS` and
|
|
`go env GOHOSTARCH`, then using those values when building its native ReleaseKit
|
|
executable. Its `TestReleaseLauncherDelegatesPublication` test supplies foreign
|
|
target variables and checks native bootstrap behavior together with argument
|
|
and exit-status forwarding. Consumer evidence is in CommandKit's
|
|
`scripts/release` and `scripts/release_test.go` at local commit
|
|
`a74fcb20041cbccde93f9b9a1e3b24cb8dd131e7`.
|
|
|
|
Please incorporate this behavior and regression coverage into ReleaseKit's
|
|
maintained consumer launcher example so downstream projects can reuse the
|
|
recipe and rely on upstream tests for its generic bootstrap mechanics.
|
|
|
|
## Observed failure
|
|
|
|
Reviewed ReleaseKit v0.8.0, commit
|
|
`23203f235cc414c4ffe0fd3941030eb0c9f9943f`. The
|
|
[multi-module launcher](../../examples/multi-module/release.sh) invokes
|
|
`go tool` without normalizing the inherited target environment.
|
|
|
|
On Linux/amd64 with Go 1.26.8, from a prepared consumer module registering
|
|
`go.maximumdirect.net/releasekit/cmd/releasekit` at v0.8.0:
|
|
|
|
```sh
|
|
GOWORK=off GOTOOLCHAIN=local GOFLAGS=-mod=readonly \
|
|
GOPROXY=off GONOPROXY=none GOSUMDB=off \
|
|
GOOS=windows GOARCH=arm64 go tool releasekit version
|
|
```
|
|
|
|
The command built a Windows executable and failed to launch it with an
|
|
`exec format error`. Repeating the command with `GOOS=linux GOARCH=amd64`
|
|
succeeded and printed `releasekit v0.8.0`. These observations establish the
|
|
tool-execution failure; the complete upstream launcher was inspected rather
|
|
than executed in this reproduction. No publication was attempted.
|
|
|
|
## Requested change
|
|
|
|
Update the maintained launcher to select the native host target when preparing
|
|
and executing ReleaseKit, regardless of inherited application target variables.
|
|
Resolve the host through the selected Go toolchain rather than hard-coding a
|
|
platform. Scope this change to running the maintainer tool; preserve the
|
|
application targets selected through existing release profiles.
|
|
|
|
Retain the launcher's existing module/version selection, profile routing,
|
|
source-file preservation, workspace/toolchain settings, and child exit-status
|
|
behavior. Document the host-target handling in the
|
|
[consumer adoption guidance](../consumers/adoption.md) where appropriate.
|
|
|
|
Prefer a small change to the supported example and its tests. This request does
|
|
not require a new validation option, public bootstrap API, or test-helper
|
|
package. CommandKit's choice to select one tool version from its root module
|
|
remains consumer-owned; this request does not change ReleaseKit's example policy
|
|
of selecting the tool from the chosen module.
|
|
|
|
## Acceptance evidence
|
|
|
|
Extend the existing
|
|
[multi-module launcher tests](../../cmd/releasekit/multi_module_example_test.go)
|
|
with a controlled foreign-target environment. Demonstrate that:
|
|
|
|
1. The selected tool executes on the host despite foreign `GOOS` and `GOARCH`.
|
|
2. The selected module's tool version and publication arguments still reach the
|
|
child, and child statuses 0, 1, 2, and 3 are preserved.
|
|
3. Source module files remain unchanged and existing bootstrap cleanup behavior
|
|
is preserved.
|
|
|
|
Reuse existing coverage for unaffected behavior rather than adding a parallel
|
|
suite. A host-run test can use a synthetic local tool and needs no real release
|
|
or external service. Synthetic module downloads must use test-owned caches as
|
|
described in [the developer guide](../development.md#testing-synthetic-modules).
|
|
|
|
## Ownership and downstream follow-up
|
|
|
|
CommandKit's review found no locally maintained candidate validator that needs
|
|
to become a new ReleaseKit feature. Existing formatting, Markdown, and module
|
|
distribution options already cover their respective reusable checks; selecting
|
|
them as CommandKit release gates is a separate consumer decision.
|
|
|
|
ReleaseKit already owns publication-engine tests for annotated tags, exact
|
|
remote objects, nested tag prefixes, and endpoint preflight. CommandKit can
|
|
narrow its local publication exercise to its launcher and profile wiring
|
|
without upstreaming a duplicate engine test suite. Its selectors, product names,
|
|
publication endpoint, and release order remain local responsibilities.
|