67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
# Adopt ReleaseKit
|
|
|
|
Use a versioned Go tool dependency when ReleaseKit provides the repository's
|
|
release commands. This records the CLI in `go.mod` and keeps it available to
|
|
maintainers without adding imports to application or library code.
|
|
|
|
## CLI tool dependency
|
|
|
|
From the consumer module's root, select the ReleaseKit version to adopt:
|
|
|
|
```sh
|
|
: "${RELEASEKIT_TOOL_VERSION:?Set the released ReleaseKit version to adopt}"
|
|
go get -tool "gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@${RELEASEKIT_TOOL_VERSION}"
|
|
go mod tidy
|
|
go tool releasekit version
|
|
```
|
|
|
|
Select a release that implements the API, profile, and workflow you are adopting.
|
|
The module-release interface requires a release containing that feature;
|
|
pre-feature versions through v0.3.0 use their corresponding historical interface.
|
|
Go records the executable package in
|
|
a `tool` directive and the module version in a `require` directive. The tool
|
|
declaration retains the dependency through `go mod tidy`. Commit the resulting
|
|
`go.mod` and `go.sum` changes. To upgrade, repeat the command with the chosen
|
|
version and review the module changes.
|
|
|
|
The Go tool dependency feature requires Go 1.24 or later. The current ReleaseKit
|
|
module declares a Go 1.26.0 minimum, so use Go 1.26.0 or later for the current
|
|
release. Tool dependencies share the consumer's module graph: their requirements
|
|
participate in dependency version selection and can raise the consumer module's
|
|
Go minimum. See the
|
|
[Go tool dependency reference](https://go.dev/ref/mod#go-mod-file-tool).
|
|
|
|
Run `go tool releasekit` from within the consumer module to use its selected
|
|
version. Follow the [CLI contract](../cli.md) for commands and exit statuses,
|
|
and the [configuration reference](../config.md) for the release profile.
|
|
|
|
## Go API consumers
|
|
|
|
Consumers importing the root `releasekit` API or
|
|
[`buildinfo`](runtime-version.md) use ordinary package dependencies. Add the
|
|
required imports and select the module version:
|
|
|
|
```sh
|
|
: "${RELEASEKIT_TOOL_VERSION:?Set the released ReleaseKit version to adopt}"
|
|
go get "gitea.maximumdirect.net/eric/ReleaseKit@${RELEASEKIT_TOOL_VERSION}"
|
|
go mod tidy
|
|
```
|
|
|
|
API consumers can also register the CLI with `go get -tool` as above. Both uses
|
|
share the module-selected ReleaseKit version.
|
|
|
|
## CI adoption
|
|
|
|
The maintained [consumer tag-delivery workflow](delivery.md#woodpecker-tag-workflows)
|
|
supports both tool and ordinary package dependencies. It builds ReleaseKit from
|
|
the tagged consumer's module selection, so the committed module files also
|
|
govern CI delivery and retries. Registering the CLI as a tool is sufficient for
|
|
consumers that use ReleaseKit only for maintainer commands.
|
|
|
|
Upgrade the module-selected tool and workflow together. For a tag created before
|
|
that upgrade, retry with the workflow matching the tool recorded at that tag.
|
|
Keep its immutable module files and tag intact. See the
|
|
[delivery guide](delivery.md#woodpecker-tag-workflows) for tagged-source bootstrap
|
|
and the [example's source verification](../../examples/multi-module/README.md#local-source-verification)
|
|
for testing an unreleased checkout in a disposable consumer repository.
|