Repository navigation
Allow targeting draft releases by release ID on GitHub - #190
Conversation
GitHub's GetReleaseByTag endpoint returns 404 for draft releases, so release view, edit, delete, and upload failed with not found on drafts. Add an ID field to forge.Release, populated by the GitHub and Gitea converters (GitLab releases carry no ID and Bitbucket does not support releases), and add a getReleaseByTagOrID helper that falls back to a numeric release ID when the tag lookup 404s. The ID path only fires after a tag 404, so existing numeric tags keep resolving by tag. The release view, edit, delete, upload, and download help text now notes that a release ID may be given instead of a tag. Signed-off-by: Rene Turcios <95189389+CloudCorpRecords@users.noreply.github.com>
andrew
left a comment
andrew
left a comment
There was a problem hiding this comment.
The fallback approach for GitHub looks right, and trying the tag first means existing numeric tags still resolve the same way. A few things before this can go in:
The new help text on view, edit, delete, upload and download says to pass the release ID instead of the tag, but only the GitHub provider accepts one. convertGiteaRelease now emits id too, while gitea/releases.go still only looks releases up with GetReleaseByTag, so a Gitea user who copies the ID from release list --json gets "not found". Please add the same 404-then-ID fallback to the Gitea provider (the SDK has GetRelease(owner, repo, id)) with tests, so the ID it prints can be used.
The doc comment on getReleaseByTagOrID is five lines that restate the code. One line is enough, something like "Draft releases 404 by tag on GitHub, so fall back to treating tag as a release ID."
In github/releases_id_test.go, drop the file-level comment block and the per-test comments that repeat the test name. The note about the /api/v3/api/uploads/ path is worth keeping, cut down to one line.
Mirror the GitHub 404-then-ID fallback in the Gitea provider so an ID copied from release list --json resolves in get, update, delete, and upload. Add fallback tests for all four paths plus the missing-tag case. Trim the getReleaseByTagOrID doc comment to one line and drop name-repeating comments in releases_id_test.go, keeping the uploads-path note as one line. Signed-off-by: Rene Turcios <95189389+CloudCorpRecords@users.noreply.github.com>
Fixes #177.
GitHub's GetReleaseByTag endpoint returns 404 for draft releases, so
forge release view,edit,delete, anduploadfailed with "not found" when given a draft release's tag.Changes:
ID int64(json:"id") toforge.Release, populated by the GitHub (r.GetID()) and Gitea (r.ID) converters. GitLab releases carry no ID field and Bitbucket does not support releases, so those providers are unchanged.getReleaseByTagOrIDhelper in the GitHub provider: it triesGetReleaseByTagfirst and, only on a 404, falls back toRepositories.GetReleasewhen the tag parses as an int64. It is now used byGet,Update,Delete, andUploadAsset. Existing numeric tags keep resolving by tag because the ID path only fires after a tag 404.release view,edit,delete,upload, anddownloadhelp text now notes that a release ID may be given instead of a tag to target draft releases. Release IDs surface automatically in JSON output via the struct tag; no new output columns were added.Tests:
TestGitHubReleaseGetByIDFallback,TestGitHubReleaseUploadAssetByIDFallback,TestGitHubReleaseUpdateByIDFallback,TestGitHubReleaseDeleteByIDFallback,TestGitHubReleaseGetMissingTagNotFound(non-numeric and numeric-but-absent tags still returnforge.ErrNotFound),TestConvertGitHubReleasePopulatesID,TestConvertGiteaReleasePopulatesID.go test ./...passes in every package,go vet ./...clean,gofmt -lclean.