Allow use of prefixes for `useGitDescribe` case.

[oliverlockwood]

Background:

• Multi-module project, where I want to release submodules separately, tag them accordingly, and base versioning on tags with separate prefixes
• In Gradle world, I would use the Axion-release plugin and configure the prefix property.
• In SBT world, I can use sbt-release for the release logic, but for deriving version numbers implicitly from tags sbt-git is the place to go.

Diving into the details in sbt-git:

• Under the covers, using useGitDescribe invokes the equivalent of git describe --tags, as documented here. For my project which includes two submodules adapters and transformers, this will always give me the tag of whatever was most recently released, rather than the one I'm interested in, for example:

    $ git describe --tags
    adapters-0.28.0-2-g4bc98ad

• What I would like to do is to be able to configure sbt-git to set a tag prefix based on which module I'm interested in. Under the covers, this could use git describe's native regex matching, i.e.

    $ git describe --tags --match "transformers-*"
    transformers-0.22.0-5-g4bc98ad
    $ git describe --tags --match "adapters-*"
    adapters-0.28.0-2-g4bc98ad

• An alternative (which I originally was looking at) would be to use a custom gitTagToVersionNumber function. However, the tags passed to this function by sbt-git are only the ones that explicitly match the current commit - the gitCurrentTags value filters out any tag whose associated commit does not exactly match the commit at HEAD - so it doesn't find "closest match" tags in the way that git describe does.
• However, I do notice that JGit doesn't yet support the --match functionality.

Next steps

I need this functionality, so I'll probably go down the road of implementing it myself. Rather than have it just a local change, I'd prefer to contribute it back as I imagine other developers may find it useful. To this end:

• Are you interested in having this functionality publicly available in sbt-git?
• If so:
  • how would you prefer to have it configured?
  • how would you prefer to have it implemented? I guess the ideal would be to add explicit JGit support for --match, and then use that; however it may be quicker to implement the --match functionality locally. Or alternatively, you may prefer to update the gitCurrentTags functionality to return all tags that relate to the current commit's history, rather than just to the current commit itself.

Thanks for your time in reading this.

[hseeberger]

Thanks for this very detailed issue description!

Before going down this route, wouldn't it make sense to consider separate Git repos? As you are releasing the subprojects individually, this looks like the cleaner setup to me.

[oliverlockwood]

Thanks for the quick response.

In some cases, using separate Git repos does make sense. However there are examples where we have many submodules which need to be released separately, but we want to group the code together so that there's not a proliferation of Git repos that developers would have to check out separately. So we still have this need.

[sdether]

I've encountered the same issue with our mono-repo that builds multiple projects with separate versioning. Without --match we can't use the automatic version generation in sbt-git. In addition the repo gets tagged with non-version tags from time to time, which also throw off the version detection.

[oliverlockwood]

@sdether and others: when I dug into this back in June, I decided the best approach would be to add --match type functionality to JGit so we could build on that. Those changes were merged into JGit (see these commits). However, there's a long release cycle for Eclipse projects, so I've been waiting for the release of that before submitting a PR for this issue.

As it happens, looking at https://projects.eclipse.org/projects/technology.jgit/releases/4.9.0/review suggests it's due to be released today (what coincidence!) but as of writing it's not on Maven Central yet.

[oliverlockwood]

PR #148 upgraded to the latest JGit, so this issue is now unblocked. I'm intending to have a look at this in the next few days.

[eliaslevy]

Any progress on this?

[oliverlockwood]

@eliaslevy other things came up and distracted me!

For the use case I have, in order to achieve what I need using sbt-git, I'll need both this issue and #144 to be resolved.

• I do intend to work on both of these when I get the chance (unless someone beats me to it... 😃)
• In the interim, I'm using a small set of extensions to sbt-release which I wrote. In case they're useful to you or anyone else in the meantime, I have open sourced them at https://github.com/oliverlockwood/sbt-release-tags-only; the artifact is available by default through SBT if you include it as follows.

  addSbtPlugin("com.oliverlockwood" % "sbt-release-tags-only" % "0.2.0")

[oliverlockwood]

Also there is in fact a PR I raised in November for this issue (#149), which has been approved but not merged as there's one open question.

I'll chase it now.

[eliaslevy]

@oliverlockwood how did you get around #144 even with your PR? I am running into the same issue with a multi project build.

[oliverlockwood]

@eliaslevy by using the separate sbt-release-tags-only plugin I wrote, linked to above (which extends sbt-release but does not use sbt-git). It's not perfect - for example, it won't give you the right information if you run sbt version - but it does allow you to perform releases with versioning based purely on git tags and not on updating a version.sbt file.

[eliaslevy]

@oliverlockwood you may be interested in changes I made to the sbt-dynver plugin.