52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# Gitea release pages
|
|
|
|
ReleaseKit's internal Gitea client verifies a hosted source tag and finds or
|
|
creates its stable release page. The public delivery facade and CLI workflow
|
|
are planned separately; this integration guide describes the implemented
|
|
internal operation.
|
|
|
|
The caller supplies the Gitea base URL, owner, repository name, and token
|
|
explicitly. The client does not read ambient credentials. The token is sent in
|
|
the `Authorization: token …` request header and is not included in errors or
|
|
results. The base URL must use HTTP or HTTPS and cannot contain URL credentials,
|
|
a query, or a fragment.
|
|
|
|
For version `vMAJOR.MINOR.PATCH`, the client first reads
|
|
`/api/v1/repos/{owner}/{repo}/tags/{tag}` and requires the hosted tag's commit
|
|
SHA to equal the captured source commit. It then reads
|
|
`/api/v1/repos/{owner}/{repo}/releases/tags/{tag}`. A matching existing page
|
|
must have that tag, the complete committed release note as its body, and stable
|
|
non-draft state. Its existing title is retained. ReleaseKit does not edit a
|
|
conflicting page.
|
|
|
|
If the page is absent, the client posts to `/api/v1/repos/{owner}/{repo}/releases`
|
|
with the selected tag and commit, the release note's H1 as title, the complete
|
|
note as body, and draft and prerelease disabled. A create conflict, interrupted
|
|
response, or malformed create response triggers one lookup. An exact page found
|
|
there confirms the existing content; a differing page is a conflict. If that
|
|
lookup cannot determine the result after a possibly successful write, the
|
|
client returns an unknown outcome. Other HTTP failures retain their structured
|
|
failure kind and status code.
|
|
|
|
For a binary-producing release, the client can build a deterministic
|
|
`SHA256SUMS` file from the declared artifact names and SHA-256 digests. Entries
|
|
are sorted by filename and use the standard two-space separator. A source-only
|
|
release produces no manifest.
|
|
|
|
Asset inspection lists the release attachments, streams each declared existing
|
|
file, and compares its SHA-256 digest. It reports each asset as matching,
|
|
missing, conflicting, or unverifiable. Same-name attachments with different
|
|
bytes are conflicts even when their reported size matches. An existing
|
|
`SHA256SUMS` must exactly match the complete expected manifest; a subset or
|
|
different manifest is a conflict. An unreadable attachment is unverifiable,
|
|
not missing. Unrelated attachments are returned separately and are preserved.
|
|
|
|
Attachment downloads and same-origin redirects carry authorization only when
|
|
their scheme, host, and port match the configured Gitea service. Cross-origin
|
|
URLs and redirects are left unrequested and reported as unverifiable. Inspection
|
|
uses GET requests only; uploads are a later delivery operation.
|
|
|
|
The integration tests use a local HTTP fixture and assert request paths,
|
|
payloads, authorization, streaming comparisons, manifest handling, and failure
|
|
handling. They do not contact a live Gitea service or use real credentials.
|