From f625674a68864396f163e5f0bf891b3c1bca6fb5 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 4 Nov 2026 01:42:03 +0000 Subject: [PATCH] Record follow up launcher review findings --- docs/roadmap/remediation.md | 54 +++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/docs/roadmap/remediation.md b/docs/roadmap/remediation.md index ed76293..d6a77ce 100644 --- a/docs/roadmap/remediation.md +++ b/docs/roadmap/remediation.md @@ -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 already fixed; the change corrects which directory is selected. Verify the 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.