1.8 KiB
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.
The integration tests use a local HTTP fixture and assert request paths, payloads, authorization, and failure handling. They do not contact a live Gitea service or use real credentials.