34 lines
1.8 KiB
Markdown
34 lines
1.8 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.
|
|
|
|
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.
|