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

Run consumer release commands through Go tools

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-02 14:46:42 +00:00
parent 6fab30337a
commit 691926d839
9 changed files with 148 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
examples/multi-module/README.md
View File

@@ -72,11 +72,14 @@ Then select a module and semantic version with the shared launcher:
The launcher copies the selected module's `go.mod` and `go.sum` to temporary
alternate module files outside the checkout, resolves ReleaseKit from that
module's local dependency selection, and builds the tool there. It invokes
`publish` with the repository profile and `--expected-module` so the library
can verify that the profile agrees with the selected table row. The temporary
files and tool are removed on exit. As with any `publish` invocation, commit the
selected module's release note and prepare its repository before publishing.
module's local dependency selection, adds the CLI tool declaration to that
temporary copy, and prepares its dependencies. It uses `go tool releasekit`
with the alternate module file to invoke `publish` with the repository profile
and `--expected-module` so the library can verify that the profile agrees with
the selected table row. Go builds and caches the executable and preserves its
exit status; the launcher removes the temporary metadata on exit. As with any
`publish` invocation, commit the selected module's release note and prepare its
repository before publishing.
If an integration depends on a sibling release, publish the dependency first,
then publish the integration with the version that consumes it. For example,
@@ -86,8 +89,9 @@ This declaration does not infer dependency order or rerun the standard suite.
The maintained [Woodpecker example](woodpecker.yml) uses the same map and
selector for root, `ckconfig`, and major-version tags. It verifies and detaches
the literal event tag before selecting the module, copies that module's metadata
outside the checkout, and builds the ReleaseKit version selected there. It then
uses `ci-deliver --prepared` with the mapped profile and expected physical module.
outside the checkout, and runs the ReleaseKit version selected there through
`go tool releasekit`. It then uses `ci-deliver --prepared` with the mapped profile
and expected physical module.
The `core-v2` profile demonstrates binary delivery; the other profiles are
page-only. Before enabling the workflow, configure each selected profile's
`delivery` object with `"forge": "gitea"`, its `base_url`, owner, and repository,