Make product checks additive

This commit is contained in:
2026-10-06 17:15:46 +00:00
parent 08093124af
commit 3e9b5c1b99
23 changed files with 368 additions and 169 deletions

View File

@@ -8,7 +8,7 @@ result, err := releasekit.Check(ctx, releasekit.ReleaseRequest{
RepositoryDir: "/work/project",
Product: "Example",
Version: "v1.2.3",
Validate: func(ctx context.Context, candidate releasekit.Candidate) error {
AdditionalChecks: func(ctx context.Context, candidate releasekit.Candidate) error {
return runProjectChecks(ctx, candidate.RepositoryDir)
},
})
@@ -24,10 +24,9 @@ version must be stable `vMAJOR.MINOR.PATCH`. The committed
product name and exact version as complete title elements. No local tag with
that version may already exist.
The callback receives the captured repository, commit, and version. ReleaseKit
calls it once. When omitted, ReleaseKit runs
`go test -mod=readonly -count=1 ./...` with the available compatible local Go
toolchain; it does not download a different toolchain automatically. The suite
ReleaseKit always runs `go test -mod=readonly -count=1 ./...` with the available
compatible local Go toolchain, then calls `AdditionalChecks` once when supplied.
It does not download a different toolchain automatically. The standard suite
uses the Go host target, disables workspace and module network access, and
ignores ambient `GOFLAGS`, experiment, and CPU feature overrides. Effective
cache and native cgo/C-tool settings are preserved, including values from Go's
@@ -36,18 +35,20 @@ cleanliness after validation.
A successful check is evidence about the local candidate only. It does not
check whether a remote branch or tag is available and does not create a tag.
The [`check` command](../cli.md) reads the product and optional validation
The [`check` command](../cli.md) reads the product and optional additional
commands from `releasekit.json`.
## Publishing the source tag
`releasekit.Publish` uses the same request and performs candidate validation,
`releasekit.Publish` uses the same request and validation order: the standard
suite runs first, followed by `AdditionalChecks` when supplied. It then performs
authoritative remote checks, annotated-tag creation, and an exact tag push. The
selected remote must publish `main` at the captured commit and must not already
contain the selected version tag. A successful result includes the endpoint and
tag object ID. Publication states distinguish an unattempted push, a tag that
was created locally but not pushed, a successful push, a guard conflict, and an
unresolved push error.
unresolved push error. See the [publication guide](publish.md) for the complete
workflow.
When a push reports an error, ReleaseKit makes one bounded query for the
authoritative tag. An exact tag object match confirms success. An absent tag is