"old" version being uploaded as release

[wolph]

While I'm still not a 100% sure it's the fault of gpgit (it could be my usage), but I'm seeing the previous commit being pushed as a release: wolph/numpy-stl#173

Some info:

• develop branch appears correct
• master branch appears correct
• tag appears correct
• built packages appear correct
• uploaded release (not tag) appears incorrect

I call gpgit from a git-flow-avh post-flow-feature-finish hook like this: https://github.com/WoLpH/dotfiles/blob/master/_git_template/hooks/post-flow-release-finish

https://github.com/WoLpH/dotfiles/blob/e423965d14f9c33f184648092e323e5b8ad47f58/_git_template/hooks/post-flow-release-finish#L21

[NicoHood]

You do not pass the branch or origin to the script. What is it used for?

You can call gpgit -d for debugging. You will see more output there. If you want to post it here, make sure your github token was hidden in the output before!

[wolph]

I'm honestly not sure how or where it's going wrong. As far as I can see the master branch, the develop branch and the tag are correct but somehow when I download the source code here, it is the previous version: https://github.com/WoLpH/numpy-stl/releases
The release files themselves are ok which makes me think it somehow links the release to the previous commit instead of the current one.

But I'm not sure if this is due to gpgit or not so I was hoping you might have an idea.

The branch and origin are automatically passed along by git-flow-avh when creating a release.

Here's the git-flow log from a release:

Branches 'develop' and 'origin/develop' have diverged.
And local branch 'develop' is ahead of 'origin/develop'.
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
Merge made by the 'recursive' strategy.
 stl/__about__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Already on 'master'
Your branch is ahead of 'origin/master' by 3 commits.
  (use "git push" to publish your local commits)
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
  (use "git push" to publish your local commits)
Already up to date.
Merge made by the 'recursive' strategy.
[GPGit gets executed here]
Deleted branch release/2.16.3 (was 41ea59f).

Summary of actions:
- Release branch 'release/2.16.3' has been merged into 'master'
- The release was tagged 'v2.16.3'
- Release tag 'v2.16.3' has been back-merged into 'develop'
- Release branch 'release/2.16.3' has been locally deleted
- You are now on branch 'develop'

And the gpgit log: log

[NicoHood]

From the log you can see, that it tags the commit COMMIT=HEAD

You can also see gpgit: line 450: BOLD: unbound variable. Which means the script crashes. Now I am wondering why you even have an output at all.

The crash needs to be fixed, I understand why that happens.

[NicoHood]

I have commited a fix for the color issue

[NicoHood]

Alright, looking at your output there seems to be something wrong with your hook. If I have the source of that hook, I can help better.

The issue is, that you are doing a merge. It looks like from dev to master possibly. But you are still tagging the dev branch. GPGit by default tags the HEAD, so that might still point to dev?

[NicoHood]

So I see that the signed release contains the correct files, while the git tag (and autogenerated github files) do not. Weird.

I have no idea why that happens, as the archive is being created based on the tag. Maybe that is not working correct?
Edit: I still have no idea. I need a complete logfile again.

[wolph]

I've downloaded the new version from your repo and tried again. The log is attached
gpgit.log

For release 2.16.3 I have not done a git push yet so everything that's visible was generated by gpgit: https://github.com/WoLpH/numpy-stl/releases

The .xz file is correct, both the .tar.gz and .zip files are not.

Upon a little closer inspection, it appears that GPGit correctly pushes the new release with the correct files, but it also pushes an incorrect Git tag. I'm not sure if that's a Github releases quirk or something else, but it appears to be creating a tag based on what is on Github at that time (before the changes are pushed): https://github.com/WoLpH/numpy-stl/tree/v2.16.3

The big issue here is... when I do a git push after creating the release, it won't push the tag anymore because gpgit already created it. Otherwise it could have fixed the issue because the local tag is correct.

[wolph]

I think I have found it. The current branch is passed as target_commitish which causes github to use that branch to create the tag.

As a workaround I can do a git push --tags before creating the gpgit release, I'm not sure if there's a better solution as Github doesn't allow creating releases with non-existing hashes.

[wolph]

That appears to work. Perhaps GPGit should default to pushing the tag before creating the release if it exists?

[NicoHood]

I dont understand. What is target_commitish?

Gpgit first creates the tag, then pushes it and afterwards creates a github release. I dont understand what you would want to improve here, as it looks "already improved to me". I guess I am completely wrong.

[wolph]

Yes, gpgit creates the tag locally. But until it is pushed, github won't know about it.

So when you create the release on github, github automatically creates a tag from the current source on github which is outdated at that point.

[NicoHood]

But the tag gets pushed first.

https://github.com/NicoHood/GPGit/blob/master/gpgit.sh#L715

Maybe the issue is, that it will tag the default branch, as it cannot detect the target branch of the tagged commit?
https://github.com/NicoHood/GPGit/blob/master/gpgit.sh#L864-L877

So the solution would be to push the commit (not the tag) on the specific branch first, so that the Github release will work?

A debug log would help a lot. Does it say "Warning Publishing release on default Github branch"?

[wolph]

That part could be the culprit in that case. The tag already exists due to git-flow-avh, but that not push it yet. In that case gpgit does not push the tag anymore.

So I guess it's just user error...

With regards to the debug log, I attached one to an earlier reply: https://github.com/NicoHood/GPGit/files/7117208/gpgit.log

In any case, perhaps a good one for the FAQ but it's the interaction between the other scripts that's causing this.

[NicoHood]

I will try to provide a fix for that, by looking up the remote:
https://stackoverflow.com/questions/6294224/check-if-pushed-tag-is-on-the-git-remote/21116365#21116365