Skip to content

feat(api): add tag prefix filtering to releases API #38513 - #38681

Open
gomitrah wants to merge 8 commits into
go-gitea:mainfrom
gomitrah:feat/38153-add-tag-prefix-filtering-releases
Open

feat(api): add tag prefix filtering to releases API #38513#38681
gomitrah wants to merge 8 commits into
go-gitea:mainfrom
gomitrah:feat/38153-add-tag-prefix-filtering-releases

Conversation

@gomitrah

@gomitrah gomitrah commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Add tag prefix filtering to /repos/{owner}/{repo}/releases API

Root Cause

The releases API endpoint currently returns all releases without a way to filter by tag prefix. In repositories with multiple artifacts or monorepo release tags, clients must fetch many pages and filter releases locally, causing unnecessary API requests and server-side processing.

Fixes #38513

Before This Change

  • API users could only fetch all releases from /repos/{owner}/{repo}/releases.
  • No query parameter was available to filter releases by tag prefix.
  • Projects with multiple release streams needed extra requests to find relevant releases.

Solution

Add support for a tag_filter query parameter in the releases API.

The API now filters releases and returns only releases whose tag names start with the provided prefix.

Implementation Details

  • Added query parameter handling for tag_filter in the releases API.
  • Applied filtering at the API/database query level instead of requiring clients to filter responses.
  • Preserved existing API behavior when tag_filter is not provided.
  • Regenerated Swagger templates (make generate-swagger) to reflect the new parameter.

gomitrah added 4 commits July 27, 2026 19:11
The pre-release param was missing its boolean type and tag_prefix
had a stray duplicate type line, causing swagger-check to fail.

Assisted-by: Claude Code:claude-sonnet-5
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jul 28, 2026
@github-actions github-actions Bot added topic/api Concerns mainly the API type/feature Completely new functionality. Can only be merged if feature freeze is not active. labels Jul 28, 2026
@silverwind

silverwind commented Jul 28, 2026

Copy link
Copy Markdown
Member
  1. How does this compare to similar GitHub APIs for releases?
  2. What about other matching mechanisms? What if someone needs suffix etc? Can we find a solution that works flexibly?

@gomitrah

gomitrah commented Jul 29, 2026

Copy link
Copy Markdown
Contributor Author
  1. How does this compare to similar GitHub APIs for releases?
  2. What about other matching mechanisms? What if someone needs suffix etc? Can we find a solution that works flexibly?

@silverwind
Thanks for the suggestion!

  1. I checked the GitHub API. GitHub's Releases API doesn't support tag prefix or other tag-based filtering; it only supports exact tag lookup (/releases/tags/{tag}) and pagination.
  2. I agree with your feedback. Based on that, I've updated the implementation to support a more flexible tag_filter instead of only prefix matching. It now supports exact, prefix, suffix, and substring matching within the same API, without introducing a new endpoint. I've pushed the changes to the existing PR. Please review and let me know if any.

@silverwind

silverwind commented Jul 29, 2026

Copy link
Copy Markdown
Member

LIKE filter is better, thank. But with those %, precise matching is not possible. Likely not an issue in practice but maybe worth a short investigation if any other APIs in gitea have solved this problem yet so that it could be adapted here.

@gomitrah

Copy link
Copy Markdown
Contributor Author

LIKE filter is better, thank. But with those %, precise matching is not possible. Likely not an issue in practice but maybe worth a short investigation if any other APIs in gitea have solved this problem yet so that it could be adapted here.

@silverwind
I looked for similar implementations in Gitea and found a reference in models/packages/conan/search.go, where wildcard matching is implemented by converting * to % (while escaping _) before using builder.Like.

I followed the same approach for tag_filter, allowing a single wildcard-based filter to support exact, prefix, suffix, and substring matching. I've updated the implementation and pushed the changes.

@silverwind silverwind left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice solution with *, thanks.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jul 29, 2026
Comment thread models/repo/release.go
Comment thread tests/integration/api_releases_test.go Outdated
Comment on lines +166 to +174
link.RawQuery = url.Values{"tag_filter": {"*1.0*"}}.Encode()
resp = MakeRequest(t, NewRequest(t, "GET", link.String()).AddTokenAuth(token), http.StatusOK)
apiReleases = DecodeJSON(t, resp, []*api.Release{})

if assert.Len(t, apiReleases, 1) {
for _, release := range apiReleases {
assert.Contains(t, release.TagName, "1.0")
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the testFilterByLen should be refactored to testFilterByTagNames and make it accept an expected names slice to "assert".

@gomitrah gomitrah Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wxiaoguang

I've refactored the test helper from testFilterByLen to testFilterByTagNames as suggested. The helper now accepts the expected tag names and validates the returned tag list directly using assert.ElementsMatch, making the test verify the actual API response instead of only the number of results. . Please review and let me know if any.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the testFilterByLen should be refactored to testFilterByTagNames and make it accept an expected names slice to "assert".

I don't understand why it still makes sense to keep the badly-designed "testFilterByLen" function .

@wxiaoguang
wxiaoguang marked this pull request as draft July 29, 2026 14:55
@wxiaoguang
wxiaoguang marked this pull request as ready for review July 30, 2026 07:16
@wxiaoguang
wxiaoguang force-pushed the feat/38153-add-tag-prefix-filtering-releases branch from 87998be to ebacc63 Compare July 30, 2026 07:23
@gomitrah
gomitrah requested a review from wxiaoguang July 31, 2026 08:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lgtm/need 1 This PR needs approval from one additional maintainer to be merged. topic/api Concerns mainly the API type/feature Completely new functionality. Can only be merged if feature freeze is not active.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add tag prefix filtering to /repos/{owner}/{repo}/releases API

4 participants