Not all new git tags are listed as release #2999

@dmolineus commented on GitHub (Mar 6, 2019):

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

@dmolineus commented on GitHub (Mar 6, 2019): No, I don't use force-push over tags at the affected repositories.

GiteaMirror commented

@lunny commented on GitHub (Mar 17, 2019):

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

@lunny commented on GitHub (Mar 17, 2019): @dmolineus have you found that on https://try.gitea.io?

GiteaMirror commented

@ghost commented on GitHub (Mar 19, 2019):

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 commented on GitHub (Mar 19, 2019): 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.

GiteaMirror commented

@ghost commented on GitHub (Mar 20, 2019):

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

@ghost commented on GitHub (Mar 20, 2019): 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

GiteaMirror commented

@lafriks commented on GitHub (Mar 25, 2019):

could you provide exact commands to reproduce that?

@lafriks commented on GitHub (Mar 25, 2019): could you provide exact commands to reproduce that?

GiteaMirror commented

@ghost commented on GitHub (Mar 25, 2019):

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 commented on GitHub (Mar 25, 2019): ```bash 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 ```

GiteaMirror commented

@ghost commented on GitHub (Mar 25, 2019):

Just added tag 3 non-annotated, no difference.

@ghost commented on GitHub (Mar 25, 2019): Just added tag `3` non-annotated, no difference.

GiteaMirror commented

@zeripath commented on GitHub (Mar 25, 2019):

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

@zeripath commented on GitHub (Mar 25, 2019): I am highly suspicious that this is, yet another, escaping issue. Perhaps related to #6321.

GiteaMirror commented

@mrsdizzie commented on GitHub (Mar 27, 2019):

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.

@mrsdizzie commented on GitHub (Mar 27, 2019): 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.

GiteaMirror commented

@HorlogeSkynet commented on GitHub (May 4, 2019):

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 commented on GitHub (May 4, 2019): 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 :wave:

GiteaMirror commented

@HorlogeSkynet commented on GitHub (May 5, 2019):

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 👋

@HorlogeSkynet commented on GitHub (May 5, 2019): 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 :wave:

GiteaMirror commented

@lunny commented on GitHub (May 6, 2019):

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

@lunny commented on GitHub (May 6, 2019): @HorlogeSkynet I put a comment there. https://github.com/go-gitea/gitea/pull/5609/files#r281054937

GiteaMirror commented

@stale[bot] commented on GitHub (Jul 5, 2019):

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.

@stale[bot] commented on GitHub (Jul 5, 2019): 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.

GiteaMirror commented

@dmolineus commented on GitHub (Jul 5, 2019):

Dear stale bot, the issue is not solved yet.

@dmolineus commented on GitHub (Jul 5, 2019): Dear stale bot, the issue is not solved yet.

GiteaMirror commented

2025-11-02 04:56:43 -06:00

@daniel-meister commented on GitHub (Aug 15, 2019):

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

@daniel-meister commented on GitHub (Aug 15, 2019): 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

GiteaMirror commented

@HorlogeSkynet commented on GitHub (Aug 25, 2019):

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 👋

@HorlogeSkynet commented on GitHub (Aug 25, 2019): 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 :wave:

GiteaMirror commented

2025-11-02 04:56:43 -06:00

@varhub commented on GitHub (Oct 3, 2019):

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.

@varhub commented on GitHub (Oct 3, 2019): 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.

GiteaMirror commented

2025-11-02 04:56:43 -06:00

@HorlogeSkynet commented on GitHub (Oct 11, 2019):

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

@HorlogeSkynet commented on GitHub (Oct 11, 2019): We are [heading towards v1.10](https://github.com/go-gitea/gitea/milestone/46) and this v1.7 regression is still not fixed. Should we simply get #5609 reverted then ?

GiteaMirror commented

@guillep2k commented on GitHub (Oct 11, 2019):

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.

@guillep2k commented on GitHub (Oct 11, 2019): 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.

GiteaMirror commented

@silverwind commented on GitHub (Oct 13, 2019):

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.

@silverwind commented on GitHub (Oct 13, 2019): 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.

GiteaMirror commented

@zeripath commented on GitHub (Oct 13, 2019):

@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?

@zeripath commented on GitHub (Oct 13, 2019): @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?

GiteaMirror commented

@HorlogeSkynet commented on GitHub (Oct 13, 2019):

@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 👋

@HorlogeSkynet commented on GitHub (Oct 13, 2019): @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_](https://github.com/go-gitea/gitea/issues/6237#issuecomment-489440989)). As you can verify [there](https://git.forestier.app/HorlogeSkynet/dotfiles/src/branch/master/.gitconfig#L19), 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 👋

GiteaMirror commented

@dmolineus commented on GitHub (Oct 15, 2019):

@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).

@dmolineus commented on GitHub (Oct 15, 2019): @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).

GiteaMirror commented