'Commits since this release' link broken for API created releases #24145
Comments
This comment was marked as outdated.
This comment was marked as outdated.
|
No. Both bug are related to the releases page counting commits, but have different reasons:
|
lunny
pushed a commit
that referenced
this issue
May 10, 2023
Fixes #24145 To solve the bug, I added a "computed" `TargetBehind` field to the `Release` model, which indicates the target branch of a release. This is particularly useful if the target branch was deleted in the meantime (or is empty). I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead of checking that a branch exists and then call `GetBranchCommit`, I immediately call `GetBranchCommit` and handle the `git.ErrNotExist` error. This optimization is covered by the added unit test.
oliverpool
added a commit
to oliverpool/gitea
that referenced
this issue
May 11, 2023
Backport go-gitea#24470 Fixes go-gitea#24145 --- To solve the bug, I added a "computed" `TargetBehind` field to the `Release` model, which indicates the target branch of a release. This is particularly useful if the target branch was deleted in the meantime (or is empty). I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead of checking that a branch exists and then call `GetBranchCommit`, I immediately call `GetBranchCommit` and handle the `git.ErrNotExist` error. This optimization is covered by the added unit test.
silverwind
pushed a commit
that referenced
this issue
May 12, 2023
Backport #24470 Fixes #24145 --- To solve the bug, I added a "computed" `TargetBehind` field to the `Release` model, which indicates the target branch of a release. This is particularly useful if the target branch was deleted in the meantime (or is empty). I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead of checking that a branch exists and then call `GetBranchCommit`, I immediately call `GetBranchCommit` and handle the `git.ErrNotExist` error. This optimization is covered by the added unit test. _contributed in the context of @forgejo_
Codeberg-org
pushed a commit
to Codeberg-org/gitea
that referenced
this issue
Jun 3, 2023
Backport go-gitea#24470 Fixes go-gitea#24145 --- To solve the bug, I added a "computed" `TargetBehind` field to the `Release` model, which indicates the target branch of a release. This is particularly useful if the target branch was deleted in the meantime (or is empty). I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead of checking that a branch exists and then call `GetBranchCommit`, I immediately call `GetBranchCommit` and handle the `git.ErrNotExist` error. This optimization is covered by the added unit test. _contributed in the context of @forgejo_ (cherry picked from commit cb7ba89)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When a release is created via the API with an empty
target, the release page is a bit broken: https://codeberg.org/forgejo-contrib/forgejo-helm/releases/tag/v0.6.1The branch bame name is missing between "to" and "since" and the
0 commitslink points to a 404 (eghttps://codeberg.org/forgejo-contrib/forgejo-helm/compare/v0.3.3...).This is related to #18226, which was fixed in #18252. The same "broken" logic is happening 50 lines below (
.Targetis an empy string):The same solution as in #18252 could be applied (stripping the
...from thehref).However I think it would be more useful to fall back to the repository default branch in such case (empty
targetfield).I would be willing to make a PR for such a "default branch fallback" solution.
Moreover the count of commits is different between the release list and the single release (tagv0.5.0for instance):https://codeberg.org/forgejo-contrib/forgejo-helm/releases
https://codeberg.org/forgejo-contrib/forgejo-helm/releases/tag/v0.5.0
=> commit count fixed in #24148
Original report: https://codeberg.org/Codeberg/Community/issues/967
Related fix for a woodpecker plugin: https://codeberg.org/woodpecker-plugins/gitea-release/pulls/9
Gitea Version
1.19 and 1.20
Can you reproduce the bug on the Gitea demo site?
Yes
How are you running Gitea?
On codeberg
contributed in the context of @forgejo
The text was updated successfully, but these errors were encountered: