When pushing only the first branch/tag gets PR/Release marked #3367

54bd63cd5c/cmd/hook.go (L193-L217)

@zeripath commented on GitHub (May 23, 2019):

This is due to the breaks in:

@zeripath commented on GitHub (May 23, 2019): This is due to the `break`s in: https://github.com/go-gitea/gitea/blob/54bd63cd5c5645202625368c185b645c7771f687/cmd/hook.go#L193-L217

GiteaMirror commented

@zeripath commented on GitHub (May 23, 2019):

Most of these should probably be continue

@zeripath commented on GitHub (May 23, 2019): Most of these should probably be `continue`

GiteaMirror commented

@zeripath commented on GitHub (May 23, 2019):

However this problem is fixed in my #6993

@zeripath commented on GitHub (May 23, 2019): However this problem is fixed in my #6993

GiteaMirror commented

181b7c99ed/models/update.go (L187-L282)

@mrsdizzie commented on GitHub (May 24, 2019):

Wouldn't this be happening in:

Calling pushUpdateAddTag() etc...?

181b7c99ed/models/update.go (L111)

I suspect what happens is that for whatever reason sometimes when a tag gets pushed that pushUpdateAddTag() fails or isn't called, and then the tag is present on the remote and never run through pushUpdateAddTag() again. There are several places pushUpdateTag() could error, and several more even before that call, but you would have already needed error logging turned on to see I think.

Migrating or mirroring these example repos like the one above shows the proper releases (both 1.0.0 and 1.0.1) because it runs SyncReleasesWithTags (which then runs pushUpdateAddTag() for each tag )which does see that tag and create a proper release:

https://try.gitea.io/mrsdizzie/bugtag

FWIW the initial comment says "I except to see in this page tag 1.0.0 (pushed with --all) "
but git push --all doesn't push tags. However, it should have then pushed both tags on the next git push --tags (which it does in my testing, and I've yet to be able to reproduce pushing a tag, or several tags at once, that doesn't generate a release for each tag).

I want to find the cause of this and fix in case of a bug, but I also wonder if it would be helpful to add a button in the repo settings that can run SyncReleasesWithTags in case of any errors like this, which would at least provide a way to recover.

@mrsdizzie commented on GitHub (May 24, 2019): Wouldn't this be happening in: https://github.com/go-gitea/gitea/blob/181b7c99eddb373b4415b160dde9109cd4191878/models/update.go#L187-L282 Calling pushUpdateAddTag() etc...? https://github.com/go-gitea/gitea/blob/181b7c99eddb373b4415b160dde9109cd4191878/models/update.go#L111 I suspect what happens is that for whatever reason sometimes when a tag gets pushed that pushUpdateAddTag() fails or isn't called, and then the tag is present on the remote and never run through pushUpdateAddTag() again. There are several places pushUpdateTag() could error, and several more even before that call, but you would have already needed error logging turned on to see I think. Migrating or mirroring these example repos like the one above shows the proper releases (both 1.0.0 and 1.0.1) because it runs SyncReleasesWithTags (which then runs pushUpdateAddTag() for each tag )which does see that tag and create a proper release: https://try.gitea.io/mrsdizzie/bugtag FWIW the initial comment says "I except to see in this page tag 1.0.0 (pushed with --all) " but ```git push --all``` doesn't push tags. However, it should have then pushed both tags on the next ```git push --tags``` (which it does in my testing, and I've yet to be able to reproduce pushing a tag, or several tags at once, that doesn't generate a release for each tag). I want to find the cause of this and fix in case of a bug, but I also wonder if it would be helpful to add a button in the repo settings that can run SyncReleasesWithTags in case of any errors like this, which would at least provide a way to recover.

GiteaMirror commented

@zeripath commented on GitHub (May 24, 2019):

That never gets called.

Look again at hook post-receive.

If you are pushing multiple things the breaks will stop the processing of everything after them.

To reproduce this just clone his repo and git push --tags to a local Gitea - only the first tag received will get a release made.

@zeripath commented on GitHub (May 24, 2019): That never gets called. Look again at hook post-receive. If you are pushing multiple things the breaks will stop the processing of everything after them. To reproduce this just clone his repo and git push --tags to a local Gitea - only the first tag received will get a release made.

GiteaMirror commented

@zeripath commented on GitHub (May 24, 2019):

#6993 fixes this because the private.HookPostReceive is called for every line in the push - but if you wanted to fix it without that just change those breaks to continue and it's fixed, however I'm not doing that as I'm certain that #6993 is a better way of doing hooks.

@zeripath commented on GitHub (May 24, 2019): #6993 fixes this because the private.HookPostReceive is called for every line in the push - but if you wanted to fix it without that just change those breaks to continue and it's fixed, however I'm not doing that as I'm certain that #6993 is a better way of doing hooks.

GiteaMirror commented

@mrsdizzie commented on GitHub (May 24, 2019):

Hm when I clone the test repo and push it to a local repo then do git push --tagsit shows both of the tags as releases.

In addition, I can do something like this:

$ git tag test1
$ git tag test2
$ git tag test3
$ git push --tags

and it will create a release for test1, test2, test3 so I don't quite understand the only first tag gets processed part. Those hooks are running but they aren't stopping pushing multiple tags.

Are you not seeing that?

@mrsdizzie commented on GitHub (May 24, 2019): Hm when I clone the test repo and push it to a local repo then do ```git push --tags```it shows both of the tags as releases. In addition, I can do something like this: ```sh $ git tag test1 $ git tag test2 $ git tag test3 $ git push --tags ``` and it will create a release for test1, test2, test3 so I don't quite understand the only first tag gets processed part. Those hooks are running but they aren't stopping pushing multiple tags. Are you not seeing that?

GiteaMirror commented

@zeripath commented on GitHub (May 24, 2019):

Weird I don't get that on master. Did you push --all before pushing --tags?

@zeripath commented on GitHub (May 24, 2019): Weird I don't get that on master. Did you push --all before pushing --tags?

GiteaMirror commented

2025-11-02 05:10:21 -06:00

@zeripath commented on GitHub (May 24, 2019):

Yeah you're right the breaks shouldn't affect tag only pushing as they should only due for branch pushing.

I was definitely able to reproduce the problem on master with:

git push --all local
git push --tags local

@zeripath commented on GitHub (May 24, 2019): Yeah you're right the breaks shouldn't affect tag only pushing as they should only due for branch pushing. I was definitely able to reproduce the problem on master with: ``` git push --all local git push --tags local ```

GiteaMirror commented

@mrsdizzie commented on GitHub (May 24, 2019):

Interesting, if I do the same thing it shows the release fine. Just so we're on the same page, I'm creating a new empty repo locally ("reproduce") and then doing this:

[mrsdizzie@mbp ~/Documents/source/github ] >  git clone https://try.gitea.io/djgreg13/bugtag.git
Cloning into 'bugtag'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
[mrsdizzie@mbp ~/Documents/source/github ] >  cd bugtag/
[mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] >  git remote add local http://localhost:3000/mrsdizzie/reproduce.git
[mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] >  git push local --all
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://localhost:3000/mrsdizzie/reproduce.git
 * [new branch]      master -> master
[mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] >  git push local --tags
Total 0 (delta 0), reused 0 (delta 0)
To http://localhost:3000/mrsdizzie/reproduce.git
 * [new tag]         1.0.0 -> 1.0.0
 * [new tag]         1.0.1 -> 1.0.1

And then I can see both releases in Gitea. Tried via SSH too just to rule out any possible difference. Do you get any logging from the pushUpdate function on your end? Or maybe you see something obvious that I'm missing in the way I am testing it?

@mrsdizzie commented on GitHub (May 24, 2019): Interesting, if I do the same thing it shows the release fine. Just so we're on the same page, I'm creating a new empty repo locally ("reproduce") and then doing this: ```sh [mrsdizzie@mbp ~/Documents/source/github ] > git clone https://try.gitea.io/djgreg13/bugtag.git Cloning into 'bugtag'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. [mrsdizzie@mbp ~/Documents/source/github ] > cd bugtag/ [mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] > git remote add local http://localhost:3000/mrsdizzie/reproduce.git [mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] > git push local --all Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To http://localhost:3000/mrsdizzie/reproduce.git * [new branch] master -> master [mrsdizzie@mbp ~/Documents/source/github/bugtag (master) ] > git push local --tags Total 0 (delta 0), reused 0 (delta 0) To http://localhost:3000/mrsdizzie/reproduce.git * [new tag] 1.0.0 -> 1.0.0 * [new tag] 1.0.1 -> 1.0.1 ``` And then I can see both releases in Gitea. Tried via SSH too just to rule out any possible difference. Do you get any logging from the pushUpdate function on your end? Or maybe you see something obvious that I'm missing in the way I am testing it?

GiteaMirror commented

2025-11-02 05:10:21 -06:00

@zeripath commented on GitHub (May 24, 2019):

Yeah that's what I did.

Hmm. I'll have to try it again.

Maybe it's an intermittent locking Heisenbug?

@zeripath commented on GitHub (May 24, 2019): Yeah that's what I did. Hmm. I'll have to try it again. Maybe it's an intermittent locking Heisenbug?

GiteaMirror commented

2025-11-02 05:10:21 -06:00

@zeripath commented on GitHub (May 24, 2019):

Just realised that in post-receive we probably shouldn't stop on error because it's too late as the commits are in the repo - so we have to complete.

It's almost like we need a transaction log or some way of getting Gitea to just refresh the whole repo - as you suggested. (This would also be useful for allowing gitea to just take over repos.)

@zeripath commented on GitHub (May 24, 2019): Just realised that in post-receive we probably shouldn't stop on error because it's too late as the commits are in the repo - so we have to complete. It's almost like we need a transaction log or some way of getting Gitea to just refresh the whole repo - as you suggested. (This would also be useful for allowing gitea to just take over repos.)

GiteaMirror commented

@mrsdizzie commented on GitHub (May 24, 2019):

I'd be curious if you have error logging on to see if there is anything coming from the pushUpdate or pushUpdateAddTag functions (as there are places it could exit before creating the release but after pushing the tag). Or just anywhere I guess! I was hoping to be able to reproduce it as you are to see whats actually happening but I can't :(

And yea perhaps SyncReleasesWithTags should be made available to the user in some way, because as of now even if you found why the release wasn't made and fixed it (or explained why it was a valid error) there is no way to make it try again.

@mrsdizzie commented on GitHub (May 24, 2019): I'd be curious if you have error logging on to see if there is anything coming from the pushUpdate or pushUpdateAddTag functions (as there are places it could exit before creating the release but after pushing the tag). Or just anywhere I guess! I was hoping to be able to reproduce it as you are to see whats actually happening but I can't :( And yea perhaps SyncReleasesWithTags should be made available to the user in some way, because as of now even if you found why the release wasn't made and fixed it (or explained why it was a valid error) there is no way to make it try again.

GiteaMirror commented

@mixman68 commented on GitHub (May 24, 2019):

Since git 2.4 there is an option for push tags with commits but it is disabled by default

git config --global push.followTags true

So if I do push --all as i tell, the follow-tags is by default to true ;)

i tested git push --mirror, this commang bugs too with tags, there are missing into release tab. Only commits are shown in timeline.

I tested with gitea 1.5, it's works fine, our previous version. So it is a regression with newer version

@mixman68 commented on GitHub (May 24, 2019): Since git 2.4 there is an option for push tags with commits but it is disabled by default git config --global push.followTags true So if I do push --all as i tell, the follow-tags is by default to true ;) i tested git push --mirror, this commang bugs too with tags, there are missing into release tab. Only commits are shown in timeline. I tested with gitea 1.5, it's works fine, our previous version. So it is a regression with newer version

GiteaMirror commented

https://git-scm.com/docs/git-push#Documentation/git-push.txt---follow-tags

@mrsdizzie commented on GitHub (May 24, 2019):

Ah, ok that is a very helpful detail! I can reproduce this now with specific steps.

The git config --global push.followTags true / --follow-tags option only works for annotated tags:

Assuming your tag was annotated. In testing, if I create an annotated tag and push it with the --follow-tags option then gitea doesn't create a release (but the tag is pushed to the server successfully). If I create an annotated tag and push it with git push --tags then it does see it.

This appears to be because of this check:

181b7c99ed/models/update.go (L222-L223)

When using git push --tags the opts.RefFullName: is refs/tags/tagname which passes that check. When using git push --all it is refs/heads/branchname and doesn't pass that test so it never runs pushUpdateAddTag.

Not sure the best way to check for tags in the git push --all situation (there doesn't appear to be enough info in opts for that currently), but that seems to be the likely cause here.

@mrsdizzie commented on GitHub (May 24, 2019): Ah, ok that is a very helpful detail! I can reproduce this now with specific steps. The git config --global push.followTags true / --follow-tags option only works for annotated tags: https://git-scm.com/docs/git-push#Documentation/git-push.txt---follow-tags Assuming your tag was annotated. In testing, if I create an annotated tag and push it with the --follow-tags option then gitea doesn't create a release (but the tag is pushed to the server successfully). If I create an annotated tag and push it with git push --tags then it does see it. This appears to be because of this check: https://github.com/go-gitea/gitea/blob/181b7c99eddb373b4415b160dde9109cd4191878/models/update.go#L222-L223 When using ```git push --tags``` the ```opts.RefFullName:``` is ``` refs/tags/tagname``` which passes that check. When using ```git push --all``` it is ``` refs/heads/branchname``` and doesn't pass that test so it never runs pushUpdateAddTag. Not sure the best way to check for tags in the git push --all situation (there doesn't appear to be enough info in opts for that currently), but that seems to be the likely cause here.

GiteaMirror commented

@zeripath commented on GitHub (May 24, 2019):

So when I first looked at this I thought this might be an annotated Vs unannotated issue but looking at the repo on try I'm not convinced either of those tags are annotated.

@zeripath commented on GitHub (May 24, 2019): So when I first looked at this I thought this might be an annotated Vs unannotated issue but looking at the repo on try I'm not convinced either of those tags are annotated.

GiteaMirror commented

@mrsdizzie commented on GitHub (May 24, 2019):

It isn't about annotate as much as it is about the RefFullName not starting with /refs/tags.

git push --all just seems to only push annotated tags (but you can push them fine with git push --tags). There are maybe other situations where you can push a tag and that RefFullName value might not start with /refs/tags also (I'm not that familiar)

@mrsdizzie commented on GitHub (May 24, 2019): It isn't about annotate as much as it is about the RefFullName not starting with /refs/tags. git push --all just seems to only push annotated tags (but you can push them fine with git push --tags). There are maybe other situations where you can push a tag and that RefFullName value might not start with /refs/tags also (I'm not that familiar)

GiteaMirror commented

@mixman68 commented on GitHub (May 24, 2019):

@mrsdizzie ,
with the --mirror option of git, i have the same issue,

In the git documentation, they tell :

--mirror

    Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.

So in the mirror push, the tag is not show in Releases tab as follow-tags behaviour, so in mirror push, /refs/tags is pushed

@mixman68 commented on GitHub (May 24, 2019): @mrsdizzie , with the --mirror option of git, i have the same issue, In the git documentation, they tell : ``` --mirror Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set. ``` So in the mirror push, the tag is not show in Releases tab as follow-tags behaviour, so in mirror push, /refs/tags is pushed

GiteaMirror commented

@zeripath commented on GitHub (May 24, 2019):

@djgreg13 would you be able to build #6993 and confirm that it solves this issue?

@zeripath commented on GitHub (May 24, 2019): @djgreg13 would you be able to build #6993 and confirm that it solves this issue?

GiteaMirror commented

@mrsdizzie commented on GitHub (May 24, 2019):

@zeripath I built that PR and it does fix the test case that I was able to reproduce as those tags are now seen by pushUpdate

@mrsdizzie commented on GitHub (May 24, 2019): @zeripath I built that PR and it does fix the test case that I was able to reproduce as those tags are now seen by pushUpdate

GiteaMirror commented