Not all new git tags are listed as release

[dmolineus]

• Gitea version (or commit ref): 1.7.3
• Git version: 2.16.5
• Operating system: Linux (Cent OS 7)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

I struggle with a strange behaviour. Since Gitea 1.7.0 it happens quite often that not all new tags are not listed on the release page. Sometimes they get added somestimes not. I have no idea why. It beheaves different on the same repository. Sometimes the tags are created sometimes not. Any idea how to find out what's going wrong?

[silverwind]

I too think something is up with inconsistent release generation. I have repos that generate a release every tag, but then I also have repos which fail to generate releases since at least half a year ago. Maybe it is related to force pushing over tags? @dmolineus do you also force-push over tags sometimes?

[dmolineus]

No, I don't use force-push over tags at the affected repositories.

[lunny]

@dmolineus have you found that on https://try.gitea.io?

[ghost]

Hi, I get no more updates to releases page after upgrading from 1.5.something to 1.7.4 in one repository. No hint, no idea.

[ghost]

master + next branch, simple git-flow style release from next, few commits, annotated tag; doesn't show up:

• https://try.gitea.io/transferkraM/github-issue-6237

[lafriks]

could you provide exact commands to reproduce that?

[ghost]

git checkout -b release/2 next
echo 2 > VERSION
git add --update
git commit -sm 'Version 2!'
git checkout master
git merge --no-ff --log release/2
git tag -a 2 -sm 'Version 2!'
git rebase release/2 next
git push origin master next --tags

[ghost]

Just added tag 3 non-annotated, no difference.

[zeripath]

I am highly suspicious that this is, yet another, escaping issue. Perhaps related to #6321.

[mrsdizzie]

This appears to be a conditional issue with the code that generates the releases and not only about particular tags themselves. If I 'migrate' the example repo here then the releases show up as you'd expect: https://try.gitea.io/mrsdizzie/github-issue-6237-migrate/releases

So it does see those tags as valid releases but isn't generating the releases when the tags are pushed in this case.

[HorlogeSkynet]

Running v1.7 branch and confirming this (strange) issue too...
Occurring with a simple repository, and two tags pushed.
They are effectively present, but no release has been automatically created.

I can run some tests if needed, bye 👋

[HorlogeSkynet]

Hey back, so I've naively reviewed the changes brought by v1.7.0, and it could be a regression added by #5609 (so ping @yasuokav & @HarshitOnGitHub).

Could anyone confirm this (or not) ?

Bye 👋

[lunny]

@HorlogeSkynet I put a comment there. https://github.com/go-gitea/gitea/pull/5609/files#r281054937

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[dmolineus]

Dear stale bot, the issue is not solved yet.

[daniel-meister]

Also ran into this issue today; we were able to reproduce the following two cases in our repository:

• git push origin master next --tags does not create a release
• first pushing the branch heads only and then git push origin --tags does create a release

[HorlogeSkynet]

Hey there, this is one more up because the feature has been broken for already three minor versions now...
As we've nailed down the regression cause, this may be an easy fix for anyone familiar with the project/language, or am I getting something wrong here ?

Bye 👋

[varhub]

I ended up in same behavior than @daniel-meister with Gitea Version: 1.7.6.
First push to remote like git push origin --tags mybranch does not generate releases.

Perhaps push tags of HEAD does not generates release info due there is none branch related to it.

[HorlogeSkynet]

We are heading towards v1.10 and this v1.7 regression is still not fixed.
Should we simply get #5609 reverted then ?

[guillep2k]

Hi, @HorlogeSkynet . There has been a couple of PRs lately regarding the parsing of tags (for example #7994). I don't know if they fix your particular issue; they might. Don't rely too much in the fact that this issue was not marked as fixed.

If you have upgraded from the 1.7.1 specified at the top at some time, please edit the comment and add some note about the latest version you've tried with.

I'd suggest you test with the latest 1.10.0-dev, or even 1.9.4 in a clean environment. You might find that the issue is indeed fixed. An easy setup is trying directly against try.gitea.io. That server gets the latest version daily.

[silverwind]

I don't see any current issues with missing releases/tags. My previous comment came down to the fact that the pusher was neither specifying --tags nor --follow-tags to git push, so they never pushed the tags to the gitea remote.

[zeripath]

@HorlogeSkynet is this definitely still an issue on master? If so, are you able to come up with a minimal failure case?

The mechanism quoted earlier doesn't fail for me on master. There must be something I'm missing.

Are you able to create a repository on try that shows this?

[HorlogeSkynet]

@zeripath Maybe. Maybe not. I have to draft some tags to check this, and currently, I cannot.

@silverwind It was definitely broken at least in March when the v1.7.0 has been drafted, after #5609 got merged (please refer to @lunny's May comments following my findings).
As you can verify there, it was not about Git follow-tags flag.

@guillep2k I have seen that the release.go file has changed a lot since March, so yeah, maybe this has been fixed, and this issue should be closed, and we may all forget this.

By the way, do you consider this solved now @dmolineus ?

Bye all 👋

[dmolineus]

@HorlogeSkynet I can't reproduce the issue right now. I'm fine to close it (and if it see the issue again I would open a new issue).

[zeripath]

OK. Sorry we couldn't find the proximate cause for this. I suspect that the change in #5609 might have revealed a bug that was then later fixed. I do think we need to review and reconsider the releases tab - There's a very recent feature request that covers this - however, as this bug is now fixed in 1.10 I'm going to close this issue.

Sorry once again that we never found out what the problem was exactly, but glad it's fixed now.

[HorlogeSkynet]

Hey over there ! I hope you all are doing okay by this beginning of 2020 👌

A simple message for :

1. Confirming this issue is now fixed (yes, a bit late, sorry) ;
2. A quick and dirty trick to make missing tags (the ones that were pushed while Gitea was actually broken) appear as Releases : git push --delete origin vX.Y.Z vA.B.C <...> && git push origin --tags.

Bye, thanks for all 👋

[camlafit]

Hello

It's old but to synthesize solution as less dirty we can do : gitea admin repo-sync-releases
as explained at https://docs.gitea.io/en-us/faq/#missing-releases-after-migrating-repository-with-tags