69 lines
3.0 KiB
Markdown
69 lines
3.0 KiB
Markdown
# ADR 0004: Select release tooling from the released application's module configuration
|
|
|
|
## Status
|
|
|
|
Accepted.
|
|
|
|
## Date
|
|
|
|
2026-10-07
|
|
|
|
## Context
|
|
|
|
Applications can declare ReleaseKit as a Go module dependency and use that
|
|
selection to build their local release tool. A separate CI version pin creates
|
|
a second declaration that maintainers must coordinate during upgrades. The two
|
|
paths can then use different ReleaseKit versions for the same release.
|
|
|
|
Hosted delivery runs after source publication and may be retried for an older
|
|
release. It needs a stable source for tool-version selection associated with
|
|
that release. [ADR 0002](0002-routine-releases.md) prioritizes reducing repeated
|
|
configuration and routine release decisions.
|
|
|
|
## Decision
|
|
|
|
For applications that declare ReleaseKit as a module dependency, the standard
|
|
integration selects the tool through the application's module configuration.
|
|
Local publication uses the candidate's module configuration. CI delivery uses
|
|
the released source's module configuration. Both paths follow the same
|
|
module-based selection approach.
|
|
|
|
CI verifies the triggering tag and commit and checks out that source before
|
|
resolving and building the release tool. Delivery retries use the same released
|
|
source for tool selection. The application maintains its ReleaseKit dependency
|
|
as the shared version declaration for these operations.
|
|
|
|
Tool bootstrap and dependency preparation remain separate from offline
|
|
validation and builds. The CI integration supplies the event, environment, and
|
|
credentials; the application profile supplies product and delivery settings.
|
|
Source publication and hosted delivery retain their separate outcomes.
|
|
|
|
Consumers using a separately installed tool and ReleaseKit's own source
|
|
bootstrap remain supported use cases. Adoption guidance describes the
|
|
appropriate bootstrap for each integration.
|
|
|
|
## Alternatives considered
|
|
|
|
- An independent CI version pin makes tool selection explicit in the workflow
|
|
and requires maintainers to coordinate it with the application's dependency.
|
|
- Selecting from the current default branch follows ongoing dependency
|
|
updates and allows delivery retries for an older release to select a newer
|
|
tool.
|
|
|
|
## Consequences
|
|
|
|
Applications using the standard module-based integration update one dependency
|
|
declaration for local publication and CI delivery. Tool selection follows the
|
|
released source when delivery is retried, preserving the release's dependency
|
|
choice as the application evolves.
|
|
|
|
CI must establish the released checkout before tool bootstrap. Its environment
|
|
must provide a compatible Go toolchain and access to the dependencies needed
|
|
to build the selected tool. Retrying delivery for an older release retains
|
|
those preparation requirements.
|
|
|
|
Maintained templates and adoption guidance must preserve this selection order.
|
|
Verification should exercise a dependency-version change and selection from
|
|
the triggering release's source. Exact commands and bootstrap mechanics belong
|
|
in the maintained integration guidance and examples.
|