Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong git describe version is being chosen #161

Closed
mrubin opened this issue Aug 24, 2018 · 17 comments · Fixed by #181
Closed

Wrong git describe version is being chosen #161

mrubin opened this issue Aug 24, 2018 · 17 comments · Fixed by #181

Comments

@mrubin
Copy link

mrubin commented Aug 24, 2018

I am trying the following build settings:

    git.useGitDescribe := true,
    git.gitTagToVersionNumber := { tag: String =>
      if (tag matches "[0-9]+\\..*") Some(tag) else None
    },
    git.uncommittedSignifier := None

Everything was working as expected for several versions (i.e. 1.5, 1.6, 1.7, 1.8, 1.9). As soon as I bumped my tag to "1.10", the detected version got stuck on "1.9". I bumped the tag to "1.11", the version I'm getting from sbt-git is still "1.9". git describe in both the project directory and via the sbt shell is showing me "1.11".

How can I debug this?

@mrubin
Copy link
Author

mrubin commented Aug 24, 2018

Note that I had a bunch of tags all pointing to the same commit. At some point this broke sbt-git. When I force-pushed an empty commit just to get "1.12" to point to a different commit, my version went from "1.9" to "1.12".

@haavardw
Copy link

haavardw commented Sep 4, 2018

Test for this case found here: haavardw@b72d9d1

Note that the current behavior is different from what git describe --tags returns.

As far as I can see this is caused by using JGit as the git-reader and JGit returns the first matching tag not considering time of creation.

@mrubin
Copy link
Author

mrubin commented Sep 4, 2018

@haavardw Thank you for reproducing the issue. The documentation mentions that if I do not have git available, I can specify useJGit. I am not doing this. I have git available. Are you suggesting that JGit is still being used under the hood?

@haavardw
Copy link

haavardw commented Sep 4, 2018 via email

@mrubin
Copy link
Author

mrubin commented Sep 11, 2018

Hi @haavardw,

I just ran into this again and this time I am unable to get past the issue. Any luck with further investigations of this issue?

@haavardw
Copy link

Sorry @mrubin, I haven't had time to look further into it. We're getting hit by this quite frequently now, so we need to prioritize it soon though..

@mrubin
Copy link
Author

mrubin commented Sep 14, 2018

@haavardw thank you - the behavior is really inconsistent. We just ran into an issue (trying to deploy to prod, of course) where the wrong version got picked. The version was 1.20. We tried the build again - this time the git version was 1.21 and that went through. It seems like the plugin has issues with multiples of 10....

@javierarrieta
Copy link

Is this fixed by #162 ? I think it is but maybe it is a different case?

@haavardw
Copy link

#162 is wrong behavior in the sense that it is different than git describe (tie-breakers should be decided based on date), but ey, I like it! It is correct in 99% of the use-cases with sbt-git and super as a work-around until jgit gets fixed. I've created this issue with jgit: https://bugs.eclipse.org/bugs/show_bug.cgi?id=538610

@haavardw
Copy link

haavardw commented Nov 1, 2018

Actually #162 doesn't really work unless the multiple tags are on HEAD so I think it should be reverted. I've pushed fixes to jgit here https://github.com/eclipse/jgit/pull/78, but nobody seems to be picking it up.. I'll try to follow up.

@lJoublanc
Copy link

Hey guys, does this help at all:
https://stackoverflow.com/questions/27796561/git-describe-does-not-provide-expected-tag

in brief, if you don't use the --annotate switch when tagging, tag describe won't pick up that tag. Is this related at all, or something entirely different? Ran into this today and was going to raise an issue but then I saw this.

@mrubin
Copy link
Author

mrubin commented Nov 30, 2018

@lJoublanc Thank you for the gotcha - I did come across the same information at some point and I do happen to use git tag -a (annotated tags) for all tags. So that's not the problem.

@haavardw
Copy link

haavardw commented Dec 3, 2018

jgit has the fix included in 5.2.0 (https://projects.eclipse.org/projects/technology.jgit/releases/5.2.0). I expect it to be included in the next 4.11 release as well.

@alexmnyc
Copy link

alexmnyc commented Mar 4, 2019

same issue here.

running "git describe" returns the correct version
checking for gitDescribedVersion in sbt returns the one behind

@alexmnyc
Copy link

alexmnyc commented Mar 4, 2019

The fix for now is to use the actual git describe

git.gitDescribedVersion := git.gitDescribedVersion(v => {
  import scala.sys.process._
  val nativeGitDescribeResult = ((shell :+ s"git describe --tags") !!).trim
  git.defaultTagByVersionStrategy(nativeGitDescribeResult)
}).value

@keweishang
Copy link

Can you try and add this libraryDependencies ++= Seq( "org.eclipse.jgit" % "org.eclipse.jgit" % "4.11.6.201812241910-r" ) in your plugins.sbt? So that sbt-git will use the jgit version 4.11.6 that has this bug fixed.

@blast-hardcheese
Copy link

Can you try and add this libraryDependencies ++= Seq( "org.eclipse.jgit" % "org.eclipse.jgit" % "4.11.6.201812241910-r" ) in your plugins.sbt? So that sbt-git will use the jgit version 4.11.6 that has this bug fixed.

This did not work for me

blast-hardcheese added a commit to blast-hardcheese/guardrail that referenced this issue Feb 4, 2021
blast-hardcheese added a commit to blast-hardcheese/guardrail that referenced this issue Feb 4, 2021
jason-yeo-paidy added a commit to jason-yeo-paidy/sbt-git that referenced this issue Apr 13, 2021
With this upgrade we could fix sbt#161
jsyeo added a commit to jsyeo/sbt-git that referenced this issue Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants