126 lines
5.6 KiB
Markdown
126 lines
5.6 KiB
Markdown
# Deliver a tagged source release
|
|
|
|
Use `releasekit.Deliver` or the `deliver` command after a source tag exists.
|
|
Delivery status is separate from source publication: a delivery problem does
|
|
not move or remove the tag, and a retry can use the same immutable version.
|
|
The operation accepts historical lightweight and annotated tags, including a
|
|
detached checkout, when the checked-out `HEAD` identifies the selected tag
|
|
commit. It does not require the old remote `main` to match.
|
|
|
|
## Command line
|
|
|
|
Add a Gitea destination to the profile:
|
|
|
|
```json
|
|
{
|
|
"product": "Example",
|
|
"delivery": {
|
|
"base_url": "https://gitea.example",
|
|
"owner": "example",
|
|
"repository": "example",
|
|
"token_env": "RELEASEKIT_GITEA_TOKEN"
|
|
}
|
|
}
|
|
```
|
|
|
|
Fetch and check out the immutable tag, then deliver it:
|
|
|
|
```sh
|
|
git checkout --detach v1.2.3
|
|
RELEASEKIT_GITEA_TOKEN="$GITEA_TOKEN" releasekit deliver v1.2.3
|
|
```
|
|
|
|
The CLI reads the named token variable only for `deliver`; its default name is
|
|
`RELEASEKIT_GITEA_TOKEN`. It verifies the local checkout and hosted tag before
|
|
creating or accepting a hosted release page. The full checked-in note is the
|
|
hosted body. A retry accepts an identical page and matching attachments, adds
|
|
only missing assets, and reports conflicts without replacing content.
|
|
|
|
With no build targets, delivery is page-only: no builder, version smoke check,
|
|
receipt, binary asset, or checksum manifest is involved. With selected targets,
|
|
the command builds the tagged source into temporary storage and delivers the
|
|
result. To use artifacts built separately, pass `--assets DIR`; the directory
|
|
must contain the private `.releasekit-build.json` receipt created by `build`.
|
|
ReleaseKit checks the receipt's repository, commit, version, resolved build
|
|
settings, and file hashes before making a remote request.
|
|
|
|
The result reports `complete`, `partial`, `conflict`, `unknown`, or
|
|
`not_attempted`, along with matching, uploaded, pending, conflicting, and
|
|
uncertain assets when known. Exit status 3 means a remote write could not be
|
|
resolved; inspect the same version and retry only after the remote state is
|
|
understood. The command does not run candidate checks or publish tags.
|
|
|
|
## Go API
|
|
|
|
Pass the Gitea credential explicitly. A `BuildResult` may be supplied for a
|
|
binary-producing release; it must identify the same tagged repository commit
|
|
and selected version, its `SourceVerified` field must confirm the completed
|
|
build's clean, unchanged source observations, and its local artifacts must still
|
|
match their digests. Cleaning the checkout after a dirty build does not make
|
|
that build eligible for delivery.
|
|
Leave `Build` nil for a source-only release.
|
|
|
|
```go
|
|
result, err := releasekit.Deliver(ctx, releasekit.DeliveryRequest{
|
|
RepositoryDir: "/work/example",
|
|
Product: "Example",
|
|
Version: "v1.2.3",
|
|
Destination: releasekit.GiteaDestination{
|
|
BaseURL: "https://gitea.example",
|
|
Owner: "example",
|
|
Repository: "example",
|
|
Token: token,
|
|
},
|
|
})
|
|
if err != nil {
|
|
// Keep the returned state and any completed asset identities for recovery.
|
|
return err
|
|
}
|
|
fmt.Println(result.State, result.ReleaseURL)
|
|
```
|
|
|
|
See the [CLI contract](../cli.md), [configuration reference](../config.md),
|
|
and [Gitea integration guide](../integrations/gitea.md) for exact settings,
|
|
exit codes, and transport behavior.
|
|
|
|
## Woodpecker tag workflows
|
|
|
|
Maintained workflow examples are available for source-only and binary delivery:
|
|
|
|
- [Source-only tag workflow](../../examples/woodpecker/tag-delivery-source-only.yml)
|
|
- [Binary tag workflow](../../examples/woodpecker/tag-delivery-binary.yml)
|
|
|
|
Copy one into the consumer repository's `.woodpecker/` directory. In its
|
|
matrix entry, set `GO_IMAGE` to a Go image compatible with the consumer module
|
|
and replace `RELEASEKIT_SOURCE` with an immutable ReleaseKit commit. The
|
|
examples deliberately contain no claimed published ReleaseKit pin. Configure
|
|
the Woodpecker repository secret `releasekit_gitea_token`; the workflow maps it
|
|
to `RELEASEKIT_GITEA_TOKEN` only for the delivery step. The repository also
|
|
needs a `delivery` profile using the default `RELEASEKIT_GITEA_TOKEN` variable.
|
|
The binary profile must declare its build targets.
|
|
|
|
The tag workflow fetches the event tag, verifies that the tag resolves to
|
|
`CI_COMMIT_SHA`, and checks out that commit detached. Woodpecker shares the
|
|
repository workspace between sequential steps, so the installed executable,
|
|
Go caches, build outputs, and build receipt remain available to later steps.
|
|
The workflow keeps its `.releasekit/` directory out of Git status using the
|
|
checkout's local exclude file.
|
|
|
|
Preparation can access the Go module proxy to install the pinned ReleaseKit
|
|
executable. The binary workflow also runs `go mod download` before the build.
|
|
The later `releasekit build` command runs with `GOPROXY=off` and
|
|
`GOTOOLCHAIN=local`; its declared binary targets and receipt are placed in
|
|
`.releasekit/assets`. Delivery then passes that directory with `--assets`.
|
|
The source-only workflow skips this build step and sends the committed note
|
|
page directly. Neither template runs `check` or `publish`.
|
|
|
|
Woodpecker runs delivery after the tag event, independently from the source
|
|
publication result. Read its workflow status as delivery status: a delivery
|
|
failure does not undo source publication. A failed, partial, or uncertain run
|
|
can be inspected and retried against the same immutable tag and commit; do not
|
|
move the tag to make a retry pass. See
|
|
[Woodpecker's environment reference](https://woodpecker-ci.org/docs/usage/environment)
|
|
for the runner-provided tag and commit variables and
|
|
[workflow syntax](https://woodpecker-ci.org/docs/usage/workflow-syntax) for tag
|
|
events, sequential steps, and the shared workspace.
|