Repository navigation
Unable to obtain git.branch property with SonarQube build #413
Description
Activity
Mhh in all honesty it wouldn't surprise me if this would be related to #287. Just out curiosity could you try
mvn clean verify git-commit-id-plugin:revision sonar:sonar?I had already tried before creating this issue, sorry I forgot to also mention this.
This is the command I tried after first failed attempts:
mvn clean verify git-commit-id:revision sonar:sonarBut at the end the result does not change:

Here is the output of
mvn clean verify git-commit-id:revision sonar:sonar -Dsonar.analysis.mode=preview -Dsonar.verbose=true -X -Dsonar.log.level=DEBUG > R:\log.txtSetting project property: git.branch -> feature/my_feature Setting project property: sonar.projectVersion -> 0.0.1-SNAPSHOT-${git.branch}Let me be very clear from the start:
This is a ugly, ugly, ugly workaround and I provide it without any warranty whatsoever...Ok so in summary I think I have finally found two workarounds, and one that is not directly usable and needs adjustments to the plugin. On a high level the workarounds can be summarized as following:
- set some magic environment variables to do the 'right' thing
- overwrite the 'sonar.projectVersion' with a third party plugin gmaven-plugin to the 'right' value
- enable the plugin to replace any property (e.g. similar to two, but the plugin's replacementProperties can currently not overwrite foreign properties like 'sonar.projectVersion' )
Workaround 1
The sonar-scanner-maven extract's its properties from System.getenv() and happens to also to respect the magic environment variable SONARQUBE_SCANNER_PARAMS.
Setting this to a JSON Object makes sonar 'use' the right values:export GIT_COMMIT=$(git rev-parse --short HEAD) export GIT_BRANCH=$(git symbolic-ref --short -q HEAD) export MVN_VERSION=$(echo '${project.version}' | mvn help:evaluate | grep -v '^[[]') export SONARQUBE_SCANNER_PARAMS="{\"sonar.projectVersion\" : \"${MVN_VERSION}-${GIT_BRANCH}\"}" mvn clean package sonar:sonarWorkaround 2
For this workaround we essentially generate the 'right' 'sonar.projectVersion' with an third party plugin. And because I couldn't get this approach to work with the
build-helper-maven-plugin,properties-maven-pluginormaven-antrun-pluginI ended up going withgmaven-plugin(sorry this sounds for me so insane that we actually now need to use groovy in maven, but whatever):<!-- make sure the git-commit-id-plugin generates a file via generateGitPropertiesFilename --> <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> <version>2.6</version> <executions> <execution> <id>get-the-git-infos</id> <goals> <goal>revision</goal> </goals> <phase>initialize</phase> </execution> </executions> <configuration> <prefix>git</prefix> <verbose>true</verbose> <skipPoms>false</skipPoms> <!-- <runOnlyOnce>true</runOnlyOnce> --> <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory> <injectAllReactorProjects>true</injectAllReactorProjects> <generateGitPropertiesFile>true</generateGitPropertiesFile> <evaluateOnCommit>HEAD</evaluateOnCommit> <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename> <replacementProperties> <replacementProperty> <property>sonar.projectVersion</property> <token>^.*$</token> <value>${project.version}-${git.branch}</value> <regex>false</regex> </replacementProperty> </replacementProperties> </configuration> </plugin> <!-- now read the generated git file and create the sonar.projectVersion property --> <plugin> <groupId>org.codehaus.gmaven</groupId> <artifactId>gmaven-plugin</artifactId> <version>1.5</version> <executions> <execution> <id>set-custom-property</id> <phase>compile</phase> <goals> <goal>execute</goal> </goals> <configuration> <source>Properties gitProperties = new Properties() new File('${project.build.outputDirectory}/git.properties').withInputStream { gitProperties.load(it) } project.properties.setProperty('sonar.projectVersion', "${project.version}-" + gitProperties.getProperty("git.branch"))</source> </configuration> </execution> </executions> </plugin>
Workaround 3 (Needs adjustment to the plugin)
For this approach I had in mind to simply use the replacementProperties to set
sonar.projectVersionto the right thing (similar to 2). However the replacementProperties currently only work with properties generated by the plugin 8not sure if I want to change that). The idea pretty much boils down to this:<plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> <version>${git-commit-id-version}</version> <executions> <execution> <id>get-the-git-infos</id> <goals> <goal>revision</goal> </goals> <phase>initialize</phase> </execution> <execution> <id>validate-the-git-infos</id> <goals> <goal>validateRevision</goal> </goals> <phase>compile</phase> </execution> </executions> <configuration> <prefix>git</prefix> <verbose>true</verbose> <skipPoms>false</skipPoms> <!-- <runOnlyOnce>true</runOnlyOnce> --> <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory> <injectAllReactorProjects>true</injectAllReactorProjects> <generateGitPropertiesFile>true</generateGitPropertiesFile> <evaluateOnCommit>HEAD</evaluateOnCommit> <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename> <replacementProperties> <replacementProperty> <property>sonar.projectVersion</property> <token>^.*$</token> <value>${project.version}-${git.branch}</value> <regex>false</regex> </replacementProperty> </replacementProperties> </configuration> </plugin>
maybe something even simpler would be possible. Like a new setting
<forceResolutionOfProperties>(or something) that goes through all the current project properties and checks if they contain any properties generated by the plugin that haven't been expanded like0.0.1-SNAPSHOT-${git.branch}. If this setting is enabled we would replace the values appropriately - Note after honering theincludeandexcludeproperties of course...TLDR
Thank you for reminding me why i stopped using maven :-)
Hope this helps and sorry for the nastiness that is involved here - it seems i con't do anything about it.
In case I ever need this again: https://docs.docker.com/samples/library/sonarqube/
Thank you for your very detailed asnwer. I did not understood the whole of it (I do not know this side of Maven), but it is clear which is the problem and possible workarounds.
I do not know if you get a notification but I can see that there is another reply from Maven issue.
Thanks for the alert - and no I don't get e-Mail notifications from Maven issues.
In summary I'd claim we have slightly distinct issues - let me summarize how I understand those two issues:
Execute Plugin with it's Plugin's Prefix and pass variable through the direct config (#287)
For #287 we essentially use the plugin configuration to pass dynamic properties and use maven's prefix resolution.
In a nutshell what we want to have is a plugin execution/configuration that looks this:<plugin> <groupId>com.test.plugins</groupId> <artifactId>testPlugin</artifactId> <version>1.0.0</version> <configuration> <project>${git.branch}</project> </configuration> <executions> <execution> <id>deploy</id> <phase>install</phase> <goals> <goal>deploy</goal> </goals> </execution> </executions> </plugin>and want to run it with it's plugin prefix (aka.
mvn com.test.plugins:testPlugin:deployMojo). That was the the original issue I filed on maven. As per response what is happening is that the prefix resolution initializes the configuration of the plugin before we had the chance to get the variablegit.branch. As a result the plugin is essentially configured with an uninitialized variable (e.g.${git.branch}). The person who commented on the maven issue claims that some user may want the value without any modifications (so the uninitialized value). A supporting factor for this argument is that someone could expect some sort of isolated execution when running a plugin with it's prefix.If a user wants to tell the plugin about the updated value you either need to integrate the plugin in a normal life-cycle (
mvn clean install), or run the plugin who generates the property beforehand (mvn pl.project13.maven:git-commit-id-plugin:revision com.test.plugins:testPlugin:deployMojo) - explained here in more detail. Alternatively the plugin who consumes the property provides some sort of support for such dynamic variable (as the sonar project does).Execute Plugin with it's Plugin's Prefix and pass variable through session / project properties (#413)
This is somewhat close to the alternative that is suggested in the maven issue. Since the configuration is initialized statically we could pass variables as System environment variables if the plugin supports such behaviour.
The sonar-scanner-maven plugin happens to supports such dynamic properties and as mentioned in one of the workarounds extract's its properties from System.getenv() and happens to also to respect the magic environment variable SONARQUBE_SCANNER_PARAMS. Using this environment variable is essentially the first suggested workaround.The second workaround is what I assume a similar issue to
the property get's initialized when we don't know the right git.branch property. I assume what is happening is that during initialization of maven (before any plugin is execution) the propertysonar.projectVersionis resolved. As mention in your issue you had set the variable to${project.version}-${git.branch}. However at that initialization stage the variablegit.branchis unresolved leading to the propertysonar.projectVersionbeing set to1.0.0-${git.branch}. The second workaround essentially overwrite the propertysonar.projectVersionat a stage where we happen to know the right value of thegit.branchand thus resulting in the right variable.This is also essentially the idea for the third workaround that leverages that the sonar plugin also checks the project properties on a project level. Essentially I want to use the functionality of the
replacementPropertiesto set thesonar.projectVersionat a stage where we happen to know the right value of thegit.branch. So in a nutshell it's the same as the second workaround without using an additional third party plugin. However as of now this plugin only allowsreplacementPropertiesthat had been generated by the plugin itself (and thus fails for the externalsonar.projectVersionproperty) and hence this workaround would need adjustments to this plugin itself (not sure about those).TLDR
I hope this makes sense and gives a better insight on what is going on. For this issue I have hope that I could simplify the problem slightly for you, however for the #287 issue as commented in the maven issue it is not expected that this will change at any time (I feel I just go ahead and close the issues as
Won't fix). Relying on system.properties certainly doesn't make it easier since it's a pain to modify those with java.Outstanding work for this plugin
Make it possible to set or overwrite external properties with
replacementProperties.I have removed the 3.0 milestone again, since the outstanding work (e.g. Make it possible to set or overwrite external properties with replacementProperties) is more complicated to achieve the desired behaviour.
Essentially the suggested configuration
<replacementProperties> <replacementProperty> <property>sonar.projectVersion</property> <token>^.*$</token> <value>${project.version}-${git.branch}</value> <regex>false</regex> </replacementProperty> </replacementProperties>results in the fact that during initialization the of the plugin the
git.branchproperty is unresolved and thus resulting in the fact that the plugin only sees0.0.3-SNAPSHOT-${git.branch}. that is certainly not desired.What would be needed here is that the plugin also attempts to resolve the variables correctly.
Memo for myself (and how to to it properly):
The maven-resources-plugin uses the filtering logic from a shared module. This particular module seems to relies on plexus' string interpolation. This assumption is also confirmed by the flatten-maven-plugin. So in a nutshell in order to have the plugin produce the right values we would need to perform this particular interpolation ourself. I can't find any method to do it any way smarter....(thanks maven).See this for possible inspiration.
== EDIT:
Check if the PluginParameterExpressionEvaluator might be the answer to this problemimport org.apache.maven.plugin.PluginParameterExpressionEvaluator; private PluginParameterExpressionEvaluator expressionEvaluator; expressionEvaluator = new PluginParameterExpressionEvaluator(session, execution); // https://github.com/spotify/docker-maven-plugin/blob/c5bbc1c4993f5dc37c96457fa5de5af8308f7829/src/main/java/com/spotify/docker/BuildMojo.java#L574 // https://maven.apache.org/ref/3.6.1/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html private String expand(final String raw) throws MojoExecutionException { final Object value; try { value = expressionEvaluator.evaluate(raw); } catch (ExpressionEvaluationException e) { throw new MojoExecutionException("Expression evaluation failed: " + raw, e); } if (value == null) { throw new MojoExecutionException("Undefined expression: " + raw); } return value.toString(); }5 remaining items
Thank you for fixing this! Encountered this exact issue, and this fix appears to be the nicest of the workarounds. When might this release to Central?
Hi,
thanks for letting me know that you also have this issue and reminding me that a release would be a good thing (usually just do one when users start asking ;)).Could you perhaps try if the latest snapshot
git-commit-id-plugin-3.0.2-20191110.102347-15fixes the issue? At least thats the last one that has been published by travisSnapshots are available via:
<pluginRepositories> <pluginRepository> <id>sonatype-snapshots</id> <name>Sonatype Snapshots</name> <url>https://oss.sonatype.org/content/repositories/snapshots/</url> </pluginRepository> </pluginRepositories>@TheSnoozer I confirm this works as described above, and in a way that fixes the issue for me. I roll forward, I test the feature, it works; I roll back, it stops working.
- Thanks for the confirmation and taking the time to test! I'll try to make a release asap. Dominic Jones <notifications@github.com> schrieb am Do., 21. Nov. 2019, 09:15:…@TheSnoozer <https://github.com/TheSnoozer> I confirm this works as described above, and in a way that fixes the issue for me. I roll forward, I test the feature, it works; I roll back, it stops working. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#413>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUIG3XRL637NQAFSCCHSOTQUY7SLANCNFSM4HIA26AQ> .
@dominic-jones version 4.0.0 is now released and available via maven-repo:
https://repo1.maven.org/maven2/pl/project13/maven/git-commit-id-plugin/4.0.0/- added a commit that references this issue
on Sep 7, 2026
Hi,
in my Maven project I have configured SonarQube analysis, and I want to use the name of the current git-branch in the analysis version.
Here is my configuration:
And here is the result

The build is triggered using
mvn clean verify sonar:sonarI added an
echooutput to make sure the property is correctly created, and there is:But when the sonarqube plugin is triggered (after the echo, so I would expect to have the property value), on SonarQube dashboard I will find the property not resolved.
Here is my current plugin configuration
I enable full log with this command
mvn clean verify sonar:sonar -Dsonar.analysis.mode=preview -Dsonar.verbose=true -X -Dsonar.log.level=DEBUG > R:\log.txtAnd found the section related to properties
As far I can see, the property are managed, but the sonar version is not resolved:
Do you know similar cases or possible solutions?