79 lines
4.1 KiB
Markdown
79 lines
4.1 KiB
Markdown
# Roadmap: host-native consumer launchers
|
|
|
|
Status: implemented.
|
|
|
|
## 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.
|
|
|
|
## Baseline before implementation
|
|
|
|
The [CommandKit feature request](commandkit-feature-request.md) 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](../../examples/multi-module/release.sh)
|
|
already selected a module and profile, copied module metadata into temporary
|
|
storage, prepared the selected ReleaseKit dependency, and invoked
|
|
`go tool releasekit`. It set `GOWORK=off` and `GOTOOLCHAIN=local` while passing
|
|
inherited `GOOS` and `GOARCH` to dependency inspection and tool execution.
|
|
|
|
The [adoption guide](../consumers/adoption.md) included a minimal `go tool`
|
|
launcher. The [single-module CI template](../../examples/woodpecker/tag-delivery.yml)
|
|
and [multi-module CI template](../../examples/multi-module/woodpecker.yml) also
|
|
invoked the selected tool without explicit host-target normalization.
|
|
|
|
The [maintainer launcher](../../scripts/release),
|
|
[source delivery template](../../examples/woodpecker/releasekit-source-delivery.yml),
|
|
and [manual delivery retry](../release.md) built and executed the tool with the
|
|
same inherited-target assumption. The CLI's [generated recovery command](../../cmd/releasekit/main.go)
|
|
inherited the target from the shell where it ran, and [recovery dependency
|
|
preparation](../../internal/gotool/recovery.go) also inherited the target.
|
|
|
|
Existing [launcher tests](../../cmd/releasekit/multi_module_example_test.go)
|
|
exercised synthetic module selection, publication arguments, child statuses
|
|
0 through 3, and preservation of source module metadata. Those fixtures provided
|
|
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](implementation.md) 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.
|