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

Expose tagged-source delivery through facade and CLI

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-05 20:39:33 +00:00
parent eb2cab78bb
commit bdf6a155b5
23 changed files with 1215 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/roadmap/implementation.md
View File

@@ -1,6 +1,6 @@
# ReleaseKit staged implementation plan
Status: In progress. Stages 1–14 are complete; later stages remain pending.
Status: In progress. Stages 1–15 are complete; later stages remain pending.
Date: 2026-10-05
@@ -794,7 +794,7 @@ an ambiguous acknowledgment. Published manifest constraints hold across reruns.
## Stage 15: Expose tagged-source delivery through the facade and CLI
Status: Pending. Depends on Stage 14.
Status: Complete. Depends on Stage 14.
1. Implement `Deliver`, its facade-owned request/result values, and conversions.
Bind source note, resolved build settings, tag commit, and hosted repository
@@ -818,6 +818,21 @@ receipt, tampered assets, and missing credentials prevent relevant writes.
Candidate tests and Git publication are not run by delivery. A delivery failure
leaves the existing source tag intact and reports only delivery failure.
Evidence: `releasekit.Deliver` and `releasekit deliver` now verify lightweight or
annotated local tags from clean, attached or detached checkouts, compare the
hosted tag commit, and use the note read from the tagged commit. The CLI loads
delivery credentials only for delivery; it builds selected tagged-source
artifacts in temporary storage or verifies a supplied build receipt and its
artifact hashes before calling the facade. Page-only fixtures create and reuse
the complete note without a main package, receipt, manifest, build, or upload.
Binary fixtures build a tagged-source executable, upload it with `SHA256SUMS`,
and accept matching page and asset content on rerun. Local server tests verify
that wrong hosted and local commits, stale build settings, tampered receipt
assets, and missing credentials prevent remote writes; the tag remains intact
after delivery failure. `go test ./...`, `go run ./internal/apicheck`, and the
Markdown whitespace check pass. All delivery checks use a local HTTP fixture;
no live Gitea service or credentials were used.
## Stage 16: Provide the common Woodpecker integration
Status: Pending. Depends on Stage 15.

6
docs/roadmap/releasekit.md
View File

@@ -56,9 +56,9 @@ cleanup.
The [architecture policy](../policy/architecture.md) owns the adopted
responsibility and dependency rules, including the runtime version boundary.
The root `releasekit` package provides the public facade for candidate
validation, source publication, and selected-target builds. Internal Gitea
page and asset-delivery operations are implemented; facade and CLI orchestration
remain planned. The separate public `buildinfo` package provides lightweight
validation, source publication, selected-target builds, and tagged-source
delivery. The Gitea page and asset-delivery client is integrated through that
facade and the CLI. The separate public `buildinfo` package provides lightweight
runtime version access.
Each facade owns its public named types and documented contracts. Public