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

Plan host native release launchers

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-04 00:43:57 +00:00
parent 373f7a69cd
commit bf07bed2ae
3 changed files with 280 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
docs/roadmap/host-native-launchers.md
View File

@@ -16,9 +16,10 @@ and describes work to be implemented after this documentation pass.
## Current baseline
CommandKit reports that a prepared v0.8.0 tool invocation on Linux/amd64 with
`GOOS=windows GOARCH=arm64` built a Windows executable and failed with an exec
format error. Its local launcher already selects the Go host target before
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.
@@ -65,89 +66,8 @@ 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.
## Work needed
### 1. Normalize the maintained multi-module launcher
**Rationale:** A consumer should be able to invoke its release launcher after
cross-build work without first repairing its shell environment.
**Target:** The selected ReleaseKit executable and its dependency preparation
use the Go host target.
**Work:** Query the host OS and architecture through the same Go toolchain used
for bootstrap, under the launcher's existing workspace and toolchain settings.
Apply both values within the tool-running scope before target-dependent Go
commands. Preserve `go tool`, temporary module metadata, selected-module version
resolution, and existing publication arguments. Use ordinary shell error handling
for host-query failures. Avoid hard-coded host values or a new bootstrap layer.
### 2. Align supported invocation recipes
**Rationale:** The same inherited-target failure can affect local and CI tool
execution. Maintained recipes should give consumers consistent behavior.
**Target:** The adoption example, consumer and maintainer launchers, CI
templates, and generated recovery commands select the host target when
preparing and invoking ReleaseKit.
**Work:** Apply the same small normalization recipe to the adoption example and
the single-module and multi-module CI templates. Preserve tag verification before
bootstrap, tagged module selection, profile routing, credentials, and temporary
metadata handling. Apply host selection to the maintainer launcher, source
delivery template, and manual delivery retry. Update the multi-module README
and consumer guidance to explain host selection and profile-owned application
targets. Document that consumers adopt the corrected launcher or template; a
module dependency upgrade alone does not rewrite their copied scripts.
Apply host selection to module-based recovery dependency preparation and to the
Go invocation printed by `publish`. Preserve registered-tool selection, private
bootstrap metadata for API-only consumers, the native executable fallback,
explicit record selection, and recovery exit statuses.
### 3. Extend existing behavioral coverage
**Rationale:** Successful execution under a foreign target directly protects
against the reported defect while existing fixtures protect delegation behavior.
**Target:** A synthetic selected tool runs on the test host despite foreign
target variables, with the current routing and cleanup behavior intact.
**Work:** Extend the existing launcher fixture with a controlled target different
from the test host. Exercise real Go tool preparation and execution; a source-text
assertion alone cannot establish that the executable runs. Verify that the
selected module's tool version and publication arguments reach the child and
that statuses 0, 1, 2, and 3 propagate. Check unchanged source module files and
existing temporary bootstrap cleanup. Reuse unaffected tests rather than adding
a parallel launcher or publication-engine suite.
Verify host selection at the dependency inspection step itself, using a
host-specific fixture or an environment assertion at `go list -deps`. Cover
affected CI/bootstrap recipes through their existing test harnesses where
practical. Extend the existing handoff tests to exercise recovery preparation
under a foreign target, then run the printed command under a foreign target in
a separate invocation. Preserve profile-selected application targets. Use
synthetic local tools and test-owned module caches under the
[fixture-isolation guidance](../development.md#testing-synthetic-modules).
The regression needs no actual publication, hosted service, or external platform
runner. Choose a representative supported foreign target instead of introducing
a platform matrix.
### 4. Validate and document adoption
**Rationale:** Consumers should be able to copy a verified recipe and reduce
their local tests to their own wiring.
**Target:** Maintained examples, guidance, and tests agree on the native bootstrap
behavior and its scope.
**Work:** Run the relevant launcher and workflow tests, the normal offline suite,
and required facade checks when implementation lands. Check shell/example syntax,
documentation links, and whitespace. Include a concise release-note entry for
the inherited-target fix and affected recipes. Explain that ReleaseKit owns
generic bootstrap and publication-engine coverage while consumers verify their
selectors and profile mapping. This does not require consumers to remove tests
that protect their own behavior.
The [implementation plan](implementation.md) defines the work to reach this
state.
## Completion evidence
@@ -157,6 +77,3 @@ Preserve selected tool identity and arguments, child-status forwarding, unchange
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.
There are no significant open design decisions for this scope. Exact shell
variable names and fixture arrangement can be selected during implementation.