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

Option to set branch used when finding HEAD commit? #338

Closed
shague opened this issue Nov 1, 2017 · 7 comments
Closed

Option to set branch used when finding HEAD commit? #338

shague opened this issue Nov 1, 2017 · 7 comments
Labels
Milestone

Comments

@shague
Copy link

shague commented Nov 1, 2017

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.

@TheSnoozer
Copy link
Collaborator

Right now there is no such option/property available inside the plugin.

May I ask what the local commit is doing?
How can you ensure that your builds are reproducible when using the local and temporary commit strategy?

@shague
Copy link
Author

shague commented Nov 1, 2017

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.

@TheSnoozer
Copy link
Collaborator

Hi, thanks for clarifying and thanks :-)
Technically it should be possible to tell the plugin on what commit it should generate the git-information. With that being said it should be possible to have an option to provide either HEAD or in your case HEAD^1 as such configuration and generate the "right" version information.

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.

@shague
Copy link
Author

shague commented Nov 2, 2017

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.

@TheSnoozer
Copy link
Collaborator

Thanks for clarifying further!
As soon as I have some time I'll investigate what could be done from the plugin's side to offer something configurable. It most likely will end up as a configuration outline where you specify <headCommit>HEAD</headCommit> (in your case you would specify <headCommit>HEAD^1</headCommit>). Not sure yet if this would work and in the end of the day it would be your configuration part so just make sure that you give the plugin the right configuration.

TheSnoozer pushed a commit to TheSnoozer/git-commit-id-maven-plugin that referenced this issue Nov 5, 2017
…en finding 'HEAD' (also allows generic references like 'HEAD^1')
TheSnoozer pushed a commit that referenced this issue Nov 6, 2017
Adressing #337, #338, #339 and other minor improvements
@TheSnoozer
Copy link
Collaborator

Hi,
thanks for the suggestion. this feature will be available in the up comming 2.2.4 release and can be used in the following way:

<!-- @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 <evaluateOnCommit>HEAD^1</evaluateOnCommit>. However to be generic as possible you can specif tags, branch references or even commit hashes - so its really up to you what you need/want.

@TheSnoozer TheSnoozer added this to the 2.2.4 milestone Nov 6, 2017
@shague
Copy link
Author

shague commented Nov 6, 2017

You da' bomb! Thanks for getting this in. Can't wait to drop this in and will let you know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants