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

Record follow up launcher review findings

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-04 01:42:03 +00:00
parent 9797f43dc4
commit f625674a68
1 changed files with 54 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
docs/roadmap/remediation.md
View File

@@ -224,3 +224,57 @@ result can appear valid for the wrong candidate.
or clear `CDPATH` for those two directory changes. The number of lookups is or clear `CDPATH` for those two directory changes. The number of lookups is
already fixed; the change corrects which directory is selected. Verify the already fixed; the change corrects which directory is selected. Verify the
copyable recipe with a conflicting `CDPATH` entry. copyable recipe with a conflicting `CDPATH` entry.
## Follow-up review after remediation
Reviewed all six implementation stages at `9797f43`. The focused launcher,
delivery, and recovery tests and the public API and dependency checks passed.
The host discovery work remains bounded to a fixed number of calls per
invocation, and recovery replacement relocation now visits each directive
once. No additional scaling issue was identified.
### Stages 1, 2, and 6: Invoke the exact registered Go tool
**Evidence:** The [multi-module launcher](../../examples/multi-module/release.sh)
and both consumer Woodpecker templates
([single-module](../../examples/woodpecker/tag-delivery.yml),
[multi-module](../../examples/multi-module/woodpecker.yml)) register the
full ReleaseKit package path, but invoke the short name `releasekit`. The
[adoption launcher](../consumers/adoption.md#select-the-go-host-target) and
[multi-module smoke recipe](../../examples/multi-module/README.md) also use
the short name. Go allows two different package paths with the same final
component in the tool declarations. With a second local tool ending in
`/cmd/releasekit`, the maintained launcher and both extracted CI command
blocks prepared the intended module, then exited with an ambiguous-tool
error. Changing only the invocation to the full package path ran the
intended host-native tool in all three probes. Recovery already invokes
the full path and is unaffected.
**Fix:** Invoke the same full package path used for registration in the
maintained launchers, templates, and copyable consumer recipes. Preserve
the selected module version, arguments, and exit status. Extend an
existing launcher fixture with a second registered tool of the same short
name and verify that only the intended tool runs.
### Stage 3: Build the manual retry tool only from a clean tagged checkout
**Evidence:** The [manual retry block](../release.md) runs `git fetch` and
`git checkout --detach` before the subshell that enables `set -e`. A
failed checkout can therefore be followed by dependency preparation, a
build, and execution from the wrong source. A successful checkout can
also carry local edits forward. Both cases were reproduced with the
documented block in disposable Git repositories and a local bare remote:
a checkout refused because of conflicting edits still ran a fixture
built from the edited source, and checking out the already selected tag
succeeded while retaining and executing a local edit. The fixture exited
successfully in both cases. ReleaseKit's normal delivery guards check
the tagged checkout after the executable has already been built and
started; they do not protect this bootstrap.
**Fix:** Include the fetch and checkout in the fail-fast subshell. Resolve
the literal tag to its commit and require a clean checkout before
downloading dependencies or building the CLI, as the
[source delivery template](../../examples/woodpecker/releasekit-source-delivery.yml)
does. Preserve the scoped host target, dependency download before the
offline build, and the existing retry arguments. Verify that checkout
failure and carried-over edits both stop before the first Go command.