4.2 KiB
Roadmap: host-native consumer launchers
Status: planned; implementation pending.
Purpose
Make ReleaseKit's maintained launchers and generated recovery commands prepare
and execute the release tool for the maintainer's host when inherited GOOS
and GOARCH select a different application target. Centralize the recipe and
regression coverage so consumers can retain small launchers and product-specific
wiring tests.
This is a launcher correctness improvement. It requires no public bootstrap API, validation option, or test-helper package. This roadmap selects no release version and describes work to be implemented after this documentation pass.
Current baseline
The CommandKit feature request describes a
prepared v0.8.0 tool invocation on Linux/amd64 with GOOS=windows GOARCH=arm64
that built a Windows executable and failed with an exec format error.
CommandKit's local launcher already selects the Go host target before
building the release executable. The report's reproduction exercised tool
execution without attempting publication.
The maintained multi-module launcher
selects a module and profile, copies module metadata into temporary storage,
prepares the selected ReleaseKit dependency, and invokes go tool releasekit.
It sets GOWORK=off and GOTOOLCHAIN=local, but inherits GOOS and GOARCH.
Target-dependent dependency inspection therefore also sees the inherited target.
The adoption guide includes a minimal go tool
launcher. The single-module CI template
and multi-module CI template also
invoke the selected tool without explicit host-target normalization.
The maintainer launcher, source delivery template, and manual delivery retry build and execute the tool with the same inherited-target assumption. The CLI's generated recovery command inherits the target from the shell where it is run, and recovery dependency preparation also inherits the target.
Existing launcher tests exercise synthetic module selection, publication arguments, child statuses 0 through 3, and preservation of source module metadata. Those fixtures provide the starting point for foreign-target regression coverage.
Targeted end state
Maintained launchers and module-based recovery use GOHOSTOS and GOHOSTARCH
from the selected Go toolchain as GOOS and GOARCH while preparing and running
ReleaseKit. The tool executes on that host even when the caller was working with
a foreign application target. Normalize before target-dependent dependency
inspection as well as tool execution. Generated recovery commands select the
host when run, using the Go toolchain that will execute the command.
Application targets continue to come from existing release profiles. The launcher's host selection preserves module-selected tool versions, profile and argument routing, source-file preservation, temporary-file cleanup, existing workspace/toolchain settings, and child exit statuses. Consumers retain their own selectors, products, endpoints, and release order.
The scope is inherited GOOS and GOARCH handling for the maintainer tool. It
does not establish a hermetic environment, broaden hardware or platform support,
or add release gates. Existing Go/toolchain failures remain ordinary bootstrap
failures. No new fallback toolchain or download policy is introduced.
The implementation plan defines the work to reach this state.
Completion evidence
Completion requires host selection before dependency inspection and successful host execution under a foreign target, including for generated recovery commands. Preserve selected tool identity and arguments, child-status forwarding, unchanged source metadata, and existing cleanup behavior. The maintained local and CI recipes and adoption guidance must use the same host-selection approach. Application build targets must retain their existing profile-driven behavior.