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

Upload missing Gitea release assets

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-05 20:05:25 +00:00
parent 692a503c26
commit eb2cab78bb
7 changed files with 656 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/integrations/gitea.md
View File

@@ -1,9 +1,9 @@
# 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.
ReleaseKit's internal Gitea client verifies a hosted source tag, finds or
creates its stable release page, inspects existing assets, and uploads missing
assets. The public delivery facade and CLI workflow are planned separately;
this guide describes the implemented internal operations.
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
@@ -43,8 +43,20 @@ 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.
URLs and redirects are left unrequested and reported as unverifiable.
The upload operation accepts only an inspection result without conflicts or
unverifiable assets. It uploads missing binaries in filename order and then the
missing `SHA256SUMS`, using multipart field `attachment` and the filename query
parameter `name`. Matching attachments are retained; unrelated and existing
attachments are never overwritten or deleted. Results keep matching, uploaded,
pending, conflicting, and uncertain identities separate. After an ambiguous
upload or an upload name conflict, the client performs one list and content
check. It does not repeat the POST when the result is missing or cannot be
verified, so a caller can retry with a new inspection.
Uploads use the configured service origin and the same explicit token header.
Source-only page delivery supplies no binary assets and creates no manifest.
The integration tests use a local HTTP fixture and assert request paths,
payloads, authorization, streaming comparisons, manifest handling, and failure