68 lines
3.6 KiB
Markdown
68 lines
3.6 KiB
Markdown
# Feature request from ConfigKit: adaptable release validation
|
|
|
|
Status: Requested by a prospective downstream consumer; not yet adopted by
|
|
ReleaseKit.
|
|
|
|
ConfigKit would like to adopt ReleaseKit's common source-release process and
|
|
retire most of its repository-owned release scripts and publication tests. It is
|
|
a source-only Go library. ConfigKit can follow ReleaseKit's existing convention
|
|
of publishing the candidate to `main` before running the tag-publication
|
|
command; it does not need binary artifacts or a different source-publication
|
|
sequence.
|
|
|
|
## Select one base Go test invocation
|
|
|
|
ReleaseKit's [candidate check](../consumers/check.md) currently runs its
|
|
standard `go test` suite before any configured additional checks. ConfigKit's
|
|
selected release validation includes a race-enabled run of its full test
|
|
suite, with a separate full vet pass. Expressing the race run as an additional
|
|
check would run the suite twice and retain avoidable consumer-specific release
|
|
wiring.
|
|
|
|
Please provide a small public API and profile capability for a consumer to
|
|
select its **one base Go test invocation** for candidate validation. The
|
|
selection should replace the default invocation, rather than add a second test
|
|
run. Without a selection, ReleaseKit's current default remains useful. Both
|
|
`Check` and `Publish`, including their CLI forms, should use the selected
|
|
invocation consistently while ReleaseKit continues to own candidate capture,
|
|
validation order, result reporting, and publication. ConfigKit needs to select
|
|
a full-suite race run with test-time vet omitted because it selects a separate
|
|
full vet pass. ReleaseKit can choose the simplest public expression of that
|
|
choice; ConfigKit is not asking for a general-purpose release pipeline or
|
|
consumer-owned orchestration.
|
|
|
|
## Evaluate shared release checks
|
|
|
|
ConfigKit also uses a separate full `go vet` pass and compile checks for Linux
|
|
amd64 and arm64. Please assess whether these checks are useful enough across
|
|
ReleaseKit consumers to offer directly through its public API and profile,
|
|
either as defaults or as selected options where product support differs.
|
|
|
|
In particular, a source-only library needs to verify that its packages compile
|
|
for selected targets without declaring executable artifacts or adding delivery
|
|
work. ReleaseKit could make that distinction available to consumers. The goal
|
|
is to keep these checks, when selected, within the same candidate validation
|
|
and publication flow without repeating work already done by the base test.
|
|
Whether race, vet, or cross-target compilation should be common defaults is a
|
|
ReleaseKit product decision; ConfigKit asks for an assessment, not a universal
|
|
new release gate.
|
|
|
|
## Optional publication endpoint expectation
|
|
|
|
ConfigKit currently identifies one expected authoritative Git destination. An
|
|
optional expected-endpoint setting in ReleaseKit's public API and profile could
|
|
let a consumer verify that the selected remote resolves to its declared
|
|
destination before publication. Please consider whether this is broadly useful
|
|
and simpler than retaining a small consumer-owned preflight check. Existing
|
|
ReleaseKit remote selection and endpoint handling should remain the common
|
|
publication model.
|
|
|
|
## Adoption outcome
|
|
|
|
A useful outcome would let ConfigKit declare its product identity, selected
|
|
validation, and any expected publication destination, then rely on ReleaseKit's
|
|
standard candidate check and tag-publication command. ConfigKit would retain
|
|
its compatibility decisions and release notes while removing duplicated release
|
|
mechanics. Source publication would still complete at the confirmed tag push;
|
|
CI and hosted delivery would remain separate from that completion point.
|