eric/ReleaseKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Resolve annotated tag events in Woodpecker delivery workflows

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-11 02:07:54 +00:00
parent 3f2a1a1052
commit f076da99b6
9 changed files with 111 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/cli.md
View File

@@ -241,8 +241,11 @@ changes the selected checkout; `--prepared` reuses a verified checkout.
Ordinary `deliver` continues to operate on already prepared source without
fetching, checking out, or downloading dependencies.
In Woodpecker, pass `CI_WORKSPACE`, `CI_COMMIT_SHA`, and `CI_COMMIT_TAG` as the
repository, expected commit, and full tag arguments. The CLI does not read
In Woodpecker, pass `CI_WORKSPACE`, the source commit resolved from
`CI_COMMIT_SHA`, and `CI_COMMIT_TAG` as the repository, expected commit, and full
tag arguments. The event ID may identify an annotated tag object; see the
[delivery guide](consumers/delivery.md#woodpecker-tag-workflows) for resolution
and workflow preparation. The CLI does not read
provider-specific environment variable names. Checkout and dependency
preparation failures return status 1; usage, profile, credential, and invalid
version errors return status 2. Final delivery uses the same statuses as

26
docs/consumers/delivery.md
View File

@@ -196,14 +196,16 @@ a `delivery` profile. Page-only and binary behavior both use this template; the
profile's build target list selects whether application binaries are built and
delivered.
Before running Go, the template fetches the explicit event tag, compares its
peeled commit with the provider's full commit ID without regard to hex case,
checks out that commit detached, and confirms the source tree is clean. It then
copies the tagged `go.mod` and any `go.sum` to a temporary directory outside
the checkout. `go list -m` confirms that the module selects ReleaseKit; Go uses
Before running Go, the template fetches the explicit event tag and independently
resolves both the tag and `CI_COMMIT_SHA` to source commits. The event ID may
identify an annotated tag object or a commit. The template requires the resolved
commits to match, checks out that commit detached, and confirms the source tree
is clean. It then copies the tagged `go.mod` and any `go.sum` to a temporary
directory outside the checkout. `go list -m` confirms that the module selects
ReleaseKit; Go uses
an alternate `-modfile` to prepare dependencies and build the selected
`cmd/releasekit` package without changing the tagged module files. The template
invokes that executable with `CI_WORKSPACE`, `CI_COMMIT_SHA`, and
invokes that executable with `CI_WORKSPACE`, the resolved event commit, and
`CI_COMMIT_TAG`. A cleanup trap removes the temporary metadata and executable.
Tool bootstrap and application artifact preparation are separate. The bootstrap
@@ -243,10 +245,12 @@ The normal Go module and build caches are sufficient. Cache mounts may be added
as deployment configuration when they help the runner; they are not needed by
the template. A separately installed executable can be installed with
`go install gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@PIN`, then run
with the same arguments:
with the same arguments. With the event object available in the CI checkout,
resolve it to its source commit before invocation:
```sh
releasekit ci-deliver --repo "$CI_WORKSPACE" --commit "$CI_COMMIT_SHA" "$CI_COMMIT_TAG"
expected_commit=$(git -C "$CI_WORKSPACE" rev-parse --verify "${CI_COMMIT_SHA}^{commit}")
releasekit ci-deliver --repo "$CI_WORKSPACE" --commit "$expected_commit" "$CI_COMMIT_TAG"
```
The module-based workflow follows the ReleaseKit version selected by the tagged
@@ -255,6 +259,12 @@ consumer module configuration when adopting a newer ReleaseKit version and
verify it with a tag fixture. The command and profile behavior are documented
in the [CLI contract](../cli.md) and [configuration reference](../config.md).
Update copied workflow YAML when adopting corrected examples. A dependency
upgrade alone leaves that copy unchanged. An older tagged workflow that passes
a raw annotated tag object ID still fails on retry. Recover delivery from the
original tagged source with the resolved event commit through the command above,
preserving the published tag and existing content.
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

16
docs/roadmap/audita-bug-report.md
View File

@@ -1,6 +1,7 @@
# Audita Bug Report: Annotated Tag IDs in Woodpecker Delivery Examples
**Status:** Reported; upstream correction requested.
**Status:** Remediated in current source; offline race-enabled workflow
verification passed.
**Reviewed release:** ReleaseKit v0.4.1, commit
`2d5a8110c61e31daf8698766114ae305d0e0e469`.
**Affected consumer:** Audita v3.1.0.
@@ -107,3 +108,16 @@ receive corrected examples; retrying an existing tag's unchanged faulty workflow
will still fail. Existing artifacts can be delivered from the original tagged
source using the resolved commit ID through the documented delivery path,
without moving the source tag or replacing published contents.
## ReleaseKit Resolution
All three maintained workflows independently resolve the event ID to its source
commit, compare it with the selected tag's commit, and pass that resolved commit
to delivery. Mismatch diagnostics show both identities. The CLI and delivery
guides describe event resolution and adoption of corrected workflow copies.
Regression coverage reproduced the annotated-tag-object failure before the fix.
The affected workflow tests passed afterward with offline module settings and
the race detector. Coverage includes annotated tag-object events, annotated and
lightweight commit events, case-insensitive object IDs, resolved delivery
arguments, unrelated-commit rejection, tagged retries, and source bootstrap.