search

qoomon / maven-git-versioning-extension

This extension will set project version, based on current Git branch or tag.
GNU General Public License v3.0
305 stars 87 forks source link

allow overriding of firstParent in git describe evaluation #226

Closed tisoft closed 1 year ago

tisoft commented 1 year ago

Support setting the firstParent option for git describe

tisoft commented 1 year ago

We have a git repo, that contains imported sources of an upstream project in the upstream branch. Each time a new version is imported, it is tagged with *vx.x.x-upstream' in that branch. We have an integration branch, that adds a custom build configuration that allows us to build the upstream project in our environment. We want to add the maven-git-versioning-extension here, but unfortunately it doesn't take the tags on the upstream into account. The cli git describe command does show those tags. The difference is, that cli has the firstParent option disabled by default, but this extension has it always enabled. This PR makes the firstParent option configurable. It defaults to true, as to stay compatible with the previous extension behavior. (My suggestion would be to set the default to false to mimic git cli better, but that should probably be in a major version bump)

gitGraph
   commit id: "initial commit"
   branch integration
   branch upstream
   checkout upstream
   commit id: "import v1.0.0" tag: "v1.0.0-upstream"
   checkout integration
   merge upstream
   commit id: "added build system" type:HIGHLIGHT
   checkout main
   commit id: "custom modification" tag: "v1.0.0-custom-1"
   merge integration
   checkout upstream
   commit id: "import v1.0.1" tag: "v1.0.1-upstream"
   checkout integration
   merge upstream
   checkout main
   merge integration
   commit id: "another custom modification" type:HIGHLIGHT

In our use-case we would set firstParent=false for the integration branch, so that for added build system commit, the tag v1.0.0-upstream is used as version base. We would set firstParent=true for the main branch, so that for the another custom modification commit, the tag v1.0.0-custom-1 is used as version base.

qoomon commented 1 year ago

LGTM. However I think we should explain that this option will only make sense within an <ref type="tag"> configuration.

tisoft commented 1 year ago

I would say it makes mostly sense not in a tag configuration, since it is used for the describe functionality. I use it in branch and rev configurations with our fork. It is also possible for a tag configuration, if you want the build to actually have a different version than the tag. (For example, you could have a configuration for tag latest, that uses describe to get the real latest tag, or something like that)

tisoft commented 1 year ago

Maybe it should be renamed describeTagFirstParent or something, to make clear, that it alters the describe functionality?

qoomon commented 1 year ago

I would say it makes mostly sense not in a tag configuration, since it is used for the describe functionality. I use it in branch and rev configurations with our fork. It is also possible for a tag configuration, if you want the build to actually have a different version than the tag. (For example, you could have a configuration for tag latest, that uses describe to get the real latest tag, or something like that)

your are right I mixed it up

qoomon commented 1 year ago

Maybe it should be renamed describeTagFirstParent or something, to make clear, that it alters the describe functionality?

sounds good to me

tisoft commented 1 year ago

I have changed the configuration option from firstParent to describeTagFirstParent.

A completely speaking name would probably be describeTagFollowFirstParentOnly, but that might be a bit too verbose. So from my point of view, this could go in.

qoomon commented 1 year ago

feel free to try version 9.4.0

tisoft commented 1 year ago

Thanks for merging. I have switched our build to the new version and it is working fine. 😄