Adopt ReleaseKit and add hosted release delivery
This commit is contained in:
@@ -5,7 +5,9 @@ A release publishes the Go source under a new Git tag, with a matching release
|
||||
note committed in the repository. The tag is annotated: it includes the release
|
||||
note text and points to the released commit. Published tags and contents are
|
||||
immutable. There is no binary, container image, generated package, or separate
|
||||
registry publication.
|
||||
registry publication. Beginning with v1.0.0, maintainers also deliver a Gitea
|
||||
release page containing the complete checked-in note after source publication.
|
||||
Source publication and hosted delivery have separate outcomes.
|
||||
|
||||
A **candidate** is the committed revision you intend to release. The
|
||||
**authoritative remote** is the repository where ConfigKit publishes releases;
|
||||
@@ -99,17 +101,27 @@ commands never install another ReleaseKit version:
|
||||
```sh
|
||||
releasekit_tmp=$(mktemp -d "${TMPDIR:-/tmp}/configkit-releasekit.XXXXXX")
|
||||
releasekit_bin="$releasekit_tmp/releasekit"
|
||||
go build -o "$releasekit_bin" gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit
|
||||
go list -m gitea.maximumdirect.net/eric/ReleaseKit
|
||||
go build -o "$releasekit_bin" go.maximumdirect.net/releasekit/cmd/releasekit
|
||||
go list -m go.maximumdirect.net/releasekit
|
||||
"$releasekit_bin" version
|
||||
```
|
||||
|
||||
This repository selects ReleaseKit v0.4.2. Use the compiled program above for
|
||||
This repository selects ReleaseKit v0.6.0. Use the compiled program above for
|
||||
publication so its exit status and publication report reach you unchanged.
|
||||
`go run` maps a nonzero child exit status to 1. ReleaseKit's child Go commands
|
||||
use the `go` found on `PATH` with `GOTOOLCHAIN=local`; keep the selected
|
||||
executable first on `PATH` through the publication command.
|
||||
|
||||
For hosted delivery, save the Gitea API token in the ignored local file
|
||||
`.releasekit/gitea-token` with owner-only permissions. The profile uses it when
|
||||
`RELEASEKIT_GITEA_TOKEN` is unset or blank; a nonblank environment value takes
|
||||
precedence. The file path resolves from the repository root, and ReleaseKit
|
||||
trims surrounding whitespace from its contents. Keep credentials out of release
|
||||
notes, diagnostic labels, command arguments, and commits. The selected
|
||||
`forbidden_files` check also rejects a committed token at that exact path;
|
||||
it does not scan other files or history. Source publication uses Git
|
||||
authentication and does not read or require this token.
|
||||
|
||||
Verify access to the authoritative remote without displaying credentials:
|
||||
|
||||
```sh
|
||||
@@ -188,7 +200,7 @@ For `publish`, interpret the program's exit status as follows:
|
||||
|
||||
| Status | Meaning | Next action |
|
||||
| --- | --- | --- |
|
||||
| `0` | Publication succeeded. | The release is complete. Optional verification can follow. |
|
||||
| `0` | Publication succeeded. | The source release is complete. Continue with hosted delivery. |
|
||||
| `1` | A known publication failure or conflict was reported. | Read the report and correct the stated problem. Preserve any published tag. |
|
||||
| `2` | The command, profile, or version is invalid. | Correct the command or configuration before trying again. |
|
||||
| `3` | The tag push outcome is still unknown. | Follow the recovery procedure below before retrying or declaring success. |
|
||||
@@ -200,7 +212,62 @@ The command does not push or repair `main`, wait for CI, or publish binaries or
|
||||
a hosted release page. A successful intended-tag publication does not require
|
||||
remote read-back or consumer retrieval; those checks remain optional.
|
||||
|
||||
## 5. Recover from a failed or uncertain tag push
|
||||
## 5. Deliver the hosted release page
|
||||
|
||||
After source publication succeeds, run local hosted delivery from the repository
|
||||
root. Keep the worktree clean and `HEAD` at the published tag's commit. Reuse the
|
||||
compiled executable from step 1. For the first release using this workflow:
|
||||
|
||||
```sh
|
||||
"$releasekit_bin" deliver v1.0.0
|
||||
```
|
||||
|
||||
For subsequent releases, substitute the selected version. The profile selects
|
||||
Gitea at `https://forge.maximumdirect.net`, owner `base-layer`, repository
|
||||
`configkit`. With no build targets, delivery creates or accepts a stable,
|
||||
non-draft release page containing the complete committed note, including its
|
||||
licensing footer. It creates no binary assets, receipts, or checksum manifest.
|
||||
An existing page with matching content is accepted; conflicting content is not
|
||||
overwritten.
|
||||
|
||||
Delivery automatically performs an authenticated, read-only repository preflight
|
||||
before hosted writes. A separate preflight before source publication is not a
|
||||
release gate. Delivery does not rerun candidate validation, publish a tag, or
|
||||
wait for CI. Hosted-service availability and delivery credentials do not gate
|
||||
source publication. Report source-publication success and hosted-delivery status
|
||||
separately.
|
||||
|
||||
| Delivery status | Meaning and next action |
|
||||
| --- | --- |
|
||||
| `0` | Delivery is complete; report the hosted release URL. |
|
||||
| `1` | Preflight was unavailable, or delivery failed, conflicted, or made partial progress. Read the reported state and correct the cause; investigate conflicts before retrying. |
|
||||
| `2` | Usage, profile, credential loading, or preflight configuration/access failed. Correct the reported problem before retrying delivery. |
|
||||
| `3` | A hosted write has an unresolved outcome. Inspect the hosted release and resolve that state before retrying. |
|
||||
|
||||
A delivery problem leaves the successfully published source tag intact. Retry
|
||||
delivery with the same immutable version after correcting the cause and
|
||||
resolving any uncertain write. For a later retry, use a clean checkout of the
|
||||
original tag, fetching that tag if needed. Build the module-selected CLI from
|
||||
that checkout using step 1's tool-build commands, without changing the tagged
|
||||
module files, and make the token available there. For example, with the tag
|
||||
available locally:
|
||||
|
||||
```sh
|
||||
release_version=v1.0.0
|
||||
git switch --detach "$release_version"
|
||||
```
|
||||
|
||||
After preparing the tool in that tagged checkout:
|
||||
|
||||
```sh
|
||||
"$releasekit_bin" deliver "$release_version"
|
||||
```
|
||||
|
||||
Do not rerun `publish`, move a tag, or replace a hosted page to repair delivery.
|
||||
If published source or content needs correction, prepare a new appropriate
|
||||
version through the normal release procedure.
|
||||
|
||||
## 6. Recover from a failed or uncertain tag push
|
||||
|
||||
The executable reports the publication state, phase, version, candidate commit,
|
||||
tag-object ID, effective endpoint, and error on standard error. After a failed
|
||||
@@ -250,7 +317,7 @@ back `main`. A conflicting published tag must never be moved or reused. A
|
||||
defect in published source requires a corrected commit, a new semantically
|
||||
appropriate version, and a matching release note.
|
||||
|
||||
## 6. Optional consumer verification
|
||||
## 7. Optional consumer verification
|
||||
|
||||
When useful or requested, read back the remote tag or retrieve the exact
|
||||
version into a new module without a local `replace` directive. These checks are
|
||||
|
||||
Reference in New Issue
Block a user