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
Option to set branch used when finding HEAD commit? #338
Comments
Right now there is no such option/property available inside the plugin. May I ask what the local commit is doing? |
I think all the commit is doing is rewriting poms to remove -SNAPSHOT from the versions. Agreed that it seems wrong not to commit since it is in the build. The commit is not used so I think it is just a mechanical step that is not needed so I am looking into removing that step. In that case everything would be good. Thanks for replying with the confirmation of no config option. And kudos to this project - it has been working really well. |
Hi, thanks for clarifying and thanks :-) However I'm kinda debating the use-case of this. I currently do not really understand why you do local commits to remove -SNAPSHOT from the versions. In my opinion everything around the maven environment and every major repository solution should be able to handle snapshots perfectly fine. As you already outlined one workaround for you would be either performing whatever change but not doing local and temporary commits or actually use the SNAPSHOT-Versions. Considering that your builds might not be even reproducible its up for a debate if the plugin lacks such feature. I'll leave the ticket open and will think about it if there are other use-cases where you might want to generate git-information from arbitrary commits. |
More details. The local changes are included in a git.bundle and that file stored on a remote server - so that the byte-match builds can be made later. The local commit is needed to make the git.bundle. Those changes are just to make the build which is why they are not committed upstream. Agreed it seems convoluted but I can't get changes to that workflow made. I do have another workaround. We use the tool for its great purpose of listing all the patches included in the distribution when the automated testing runs. It relies on having the git.properties file with a known commit.id - which blows up as noted in this case. But, as part of the build process mentioned earlier, another file is stored with the git.bundle that lists all the HEAD commits on the branches before the local commit is done. I can grab that file, pull out the hash and have the same info that git.properties would provide. It is a special case just for these builds. |
Thanks for clarifying further! |
…en finding 'HEAD' (also allows generic references like 'HEAD^1')
Hi, <!-- @since 2.2.4 -->
<!--
Allow to tell the plugin what commit should be used as reference to generate the properties from.
By default this property is simply set to `HEAD` which should reference to the latest commit in your repository.
In general this property can be set to something generic like `HEAD^1` or point to a branch or tag-name.
To support any kind or use-case this configuration can also be set to an entire commit-hash or it's abbreviated version.
Please note that for security purposes not all references might be allowed as configuration.
If you have a specific use-case that is currently not white listed feel free to file an issue.
-->
<evaluateOnCommit>HEAD</evaluateOnCommit> For your use-case it seems to be sufficient to specify |
You da' bomb! Thanks for getting this in. Can't wait to drop this in and will let you know. |
Is there an option to choose what branch is used when looking up the HEAD commit that is put into the git.properties? I have a build workflow that clones the remote repo, does a local commit, then does the build, and does not push that last, local commit to the remote repo. In this case, the git.properties now has the local commit which doesn't map to anything since it was local and temporary.
I was wondering if there was a config where I could set the branch to be origin/master so that the commit HEAD would come from there.
The text was updated successfully, but these errors were encountered: