Git-commit-id-maven-plugin: Exception caught: The template variable 'git.commit.id.abbrev' has no value

[jbako-gn]

```
pl.project13.maven
git-commit-id-plugin
2.2.1



revision

initialize



true
true

``` <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>0.4.3</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <dockerDirectory>${project.basedir}</dockerDirectory>
                    <imageName>gracenote/blobservice:${git.commit.id.abbrev}</imageName>
                </configuration>
            </plugin>

Running the docker:build maven target fails with:
Exception caught: The template variable 'git.commit.id.abbrev' has no value

Any tips?

[ktoso]

more details please? Do you have a git repo where you run this?
Please paste code with a triple ` if it's multi line code.

[jbako-gn]

This is in a git repo - this is from a single pom.xml at the module root. I'm trying to follow this guide:
https://www.alooma.com/blog/building-dockers

Apparently they reference both plugins in the same pom.xml, but I can't seem to get the latter plugin to resolve the ${git.commit.id.abbrev} properly. I can see the git.properties created and it has the correct values. It's just Maven itself doesn't seem to know what to do with that particular variable.

Thanks for the edit/tip on the md style, was trying to figure that out...

[TheSnoozer]

Hey,
are you only running the mvn docker:build command?
AFAIK this would only execute the docker plugin itself and therefore the maven-git-commit-id-plugin never would have had the chance to determine some properties.
I' not sure if you are familiar with maven, but it's based on different execution phases that have a particular order (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).

In order to help us to get this solved, please do the following:
0) post your current pom, not just snippets (exclude passwords and credentials)
1) post the original command u executed
2) post the mvn log from 1)
3) execute mvn clean package
4) post the mvn log from 3)

Let us know if 3) fixed it ;-)

Thanks,

[khrisrichardson]

@jbako-gn it's worth noting that if your pom packaging type is pom, you'll need to add this to your plugin configuration...

<skipPoms>false</skipPoms>

[slowteetoe]

@jbako-gn fwiw, I was trying to follow the same guide and ended up here, few things that made a difference for me:
1) use mvn package docker:build or mvn clean package docker:build for this
2) (not related to this plugin) You can move the image tag to it's own section in the docker-maven-plugin. This gets rid of the error message and gets you an image at least tagged 'latest' (although not the git SHA like you wanted)

<configuration>
    <dockerDirectory>${project.basedir}</dockerDirectory>
    <imageName>gracenote/blobservice:</imageName>
    <imageTags>
        <imageTag>${git.commit.id.abbrev}</imageTag>
        <imageTag>latest</imageTag>
    </imageTags>
</configuration>

3) I don't know if this is a bug or just expected behavior with the maven-git-commit-id plugin, but if I used <generateGitPropertiesFile>true</generateGitPropertiesFile>, I only got a 'latest' tag, meaning, as far as I can tell, git.commit.id.abbrev was unset. If, however, I set that property to false, then I got an image tagged with the git SHA (git.commit.id.abbrev was set), as well as 'latest'.

[renannprado]

@slowteetoe I was able to get the same behavior with injectAllReactorProjects set to true.

[TheSnoozer]

this sounds related to this issue (different plugin same outcome):
https://github.com/ktoso/maven-git-commit-id-plugin/issues/287

In a nutshell maven seems to behave different when calling a maven plugin via the Plugin's Prefix (e.g. mvn somePrefix:goal) VS introduce an execution-tag and the plugin's config with a specific goal and call it with mvn clean package

I would suggest to use the suggested config from the original bug report:

<plugin>
<groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>0.4.3</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <dockerDirectory>${project.basedir}</dockerDirectory>
                    <imageName>gracenote/blobservice:${git.commit.id.abbrev}</imageName>
                </configuration>
            </plugin>

and call the build with mvn clean package according to the execution-tag the build-goal of this specific plugin will be called during package phase and thus it should work....

Read more about this here:
https://issues.apache.org/jira/browse/MNG-6260

Maven Bug Report

[TheSnoozer]

There was an update on the relevant Maven issue.
Essentially running the plugin via the Plugin's Prefix (e.g. mvn somePrefix:goal) might only be able to get the unresolved properties. The problem (based on the discussion in the maven issue) essentially boils down that the configuration of the docker plugin get's initialized before the {git.commit.id.abbrev} is available. Based on the comments in this ticket it seems that most of the users could get the build working. IMHO it is essential to set injectAllReactorProjects to true to have the property available in the pom. Currently there are two different problems known with the plugin prefix (for details see here)

If anyone still has any problem, please reopen this issue, since based on the discussions it seems to be working.

[roc-wong]

@slowteetoe I was able to get the same behavior with injectAllReactorProjects set to true.

It works. Thank you very much.