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

Unable to obtaing git.branch property #287

Closed
NicolaSpreafico opened this issue Jun 22, 2017 · 31 comments
Closed

Unable to obtaing git.branch property #287

NicolaSpreafico opened this issue Jun 22, 2017 · 31 comments

Comments

@NicolaSpreafico
Copy link

NicolaSpreafico commented Jun 22, 2017

Hi,
I discovered your plugin from here: https://stackoverflow.com/a/13975553
My goal is very simple, having the git branch name inside the build version.

Here is I come so far

<plugin>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
    <version>2.2.2</version>
    <executions>
        <execution>
            <id>get-the-git-infos</id>
            <goals>
                <goal>revision</goal>
            </goals>
        </execution>
    </executions>
</plugin>

And then the property
<deploy.version>test-${git.branch}</deploy.version>

But the variable is not resolved
[DEBUG] (f) version = test-${git.branch}

Am I missing a basic configuration?

I tried to launch the
pl.project13.maven:git-commit-id-plugin:revision
goal manually and there is no error

Because my filesystem is like this

.../.git
.../project/pom.xml

I also added this configuration, but no changes

<configuration>
    <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory>
</configuration>

I also tried to generate the external properties files in order to see if the data is properly gathered from my repo, but no file is created

<!-- this is false by default, forces the plugin to generate the git.properties file -->
<generateGitPropertiesFile>true</generateGitPropertiesFile>

<!-- The path for the properties file to be generated. See Super Pom for default variable reference https://maven.apache.org/guides/introduction/introduction-to-the-pom.html -->
<generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>

Tha main problem here is that I'm not seeing any error, so I'm going a little blind understanding the problem.

Thanks

@TheSnoozer
Copy link
Collaborator

By default the plugin doesn't expose the properties into the maven cycle.
However if you set <injectAllReactorProjects>true</injectAllReactorProjects> you should be able to use the properties within your maven-file and for the outlined scenario.

@NicolaSpreafico
Copy link
Author

NicolaSpreafico commented Jul 7, 2017

Here is my current configuration

<plugin>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
    <version>2.2.2</version>
    <configuration>
        <dotGitDirectory>${project.basedir}/../.git</dotGitDirectory>
        <injectAllReactorProjects>true</injectAllReactorProjects>
    </configuration>
    <executions>
        <execution>
            <id>get-the-git-infos</id>
            <goals>
                <goal>revision</goal>
            </goals>
        </execution>
    </executions>
</plugin>

with this property

<app.version>${git.branch}-${maven.build.timestamp}</app.version>

but I'm still having the variable unresolved

Bad value [${git.branch}-2017-07-07]: May only contain lowercase letters, digits, and hyphens.

@TheSnoozer
Copy link
Collaborator

Mhh that is somewhat strange.
I tested this with the following:

<profile>
		<id>demo</id>
		<build>
			<finalName>${git.branch}-${maven.build.timestamp}</finalName>
			<plugins>
				<plugin>
					<groupId>pl.project13.maven</groupId>
					<artifactId>git-commit-id-plugin</artifactId>
					<version>2.2.2</version>
					<configuration>
						<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
						<injectAllReactorProjects>true</injectAllReactorProjects>
					</configuration>
					<executions>
						<execution>
							<id>get-the-git-infos</id>
							<goals>
								<goal>revision</goal>
							</goals>
						</execution>
					</executions>
				</plugin>
			</plugins>
		</build>
	</profile>

mvn clean package -Pdemo will result in a jar called target/master-2017-07-08T14:05:54Z.jar

can you do the following:

  1. verify that the git-directory is located in ${project.basedir}/../.git
  2. Set <verbose>true</verbose> inside the git-commit-id-plugin config section
  3. Set <failOnNoGitDirectory>true</failOnNoGitDirectory> inside the git-commit-id-plugin config section
  4. Set <failOnUnableToExtractRepoInfo>true</failOnUnableToExtractRepoInfo> inside the git-commit-id-plugin config section
  5. since it seems that you may have a parent / child project relation ship; where do you execute your build (inside the parent or child)?
  6. What is the output of git branch -a inside ${project.basedir}/../-Directory?

@NicolaSpreafico
Copy link
Author

NicolaSpreafico commented Jul 10, 2017

Hello,

  1. I can confirm you the directory structure
../.git
../project/pom.xml
  1. I do not have a parent/child project, the project folder exists only because the repository holds additional files which are not related to Maven itself (like internal logs, schemes, ...)

  2. Here the output
    image

After added the flag you asked, here is part of the generated output

[INFO] --- git-commit-id-plugin:2.2.2:revision (get-the-git-infos) @ my-project ---
[INFO] dotGitDirectory D:\Documenti\Java\workspace.noovle\my-project-folder\project\..\.git
[INFO] git.build.user.name Nicola Spreafico
[INFO] git.build.user.email nicola.spreafico@xxxxxx
[INFO] git.branch develop
[INFO] --always = true
[INFO] --dirty = -dirty
[INFO] --abbrev = 7
.....

The develop branch is recognized, but I'm having the same problem on the generated property

[INFO] GCLOUD: Temporary staging for module default directory left in D:\Documenti\Java\workspace.noovle\my-project-folder\project\target\appengine-staging
lug 10, 2017 8:14:31 AM com.google.cloud.tools.appengine.cloudsdk.CloudSdk logCommand
INFORMAZIONI: submitting command: C:\Users\Nicola\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\gcloud.cmd app deploy D:\Documenti\Java\workspace.noovle\my-project-folder\project\target\appengine-staging\app.yaml --no-promote --version ${git.branch}-2017-07-10T06:13:15Z --project xxxxx
[INFO] GCLOUD: ERROR: (gcloud.app.deploy) argument --version/-v: Bad value [${git.branch}-2017-07-10T06:13:15Z]: May only contain lowercase letters, digits, and hyphens. Must begin and end with a letter or digit. Must not exceed 63 characters.
```f

@TheSnoozer
Copy link
Collaborator

Based on the feedback it seems that the plugin itself can retrieve the information....

How do you invoke the GCLOUD (that currently has the error with the bad value)?
Or in other words:

  • Is this a maven plugin that is getting the parameters through the pom?
  • Is the a maven plugin that is getting the parameters through a file?

If it is a file i would double check if the file is getting filtered.
If it through the pom I would double check if the properties gets exposed inside the pom.

Use something like this for debugging purposes:

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
            <phase>package</phase>
            <configuration>
                <target>
                    <echo>Extracted git-Branch: ${git.branch}</echo>
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

@NicolaSpreafico
Copy link
Author

NicolaSpreafico commented Jul 10, 2017

Gcloud is a Maven Plugin which is launched with goal deploy
This is the configuration

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>appengine-maven-plugin</artifactId>
    <version>${appengine.maven.plugin.version}</version>
    <configuration>
        <deploy.version>${app.version}</deploy.version>
        <deploy.project>${app.id}</deploy.project>
        <deploy.promote>False</deploy.promote>
    </configuration>
</plugin>

The <deploy.version>${app.version}</deploy.version> configuration is the one that received the build version, which is a property declared (as reported before) as <app.version>${git.branch}-${maven.build.timestamp}</app.version>

So I can say that the it gets the values from the pom itself. It seems like the property is not well handled

So I tried to use directly the property values inside the configuration

<deploy.version>${git.branch}-${maven.build.timestamp}</deploy.version>

But i'm getting the same error
GCLOUD: ERROR: (gcloud.app.deploy) argument --version/-v: Bad value [${git.branch}-2017-07-10]: May only contain lowercase letters, digits, and hyphens

@TheSnoozer
Copy link
Collaborator

can you provide an example project where i can reproduce this?

What is the output of

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
            <phase>package</phase>
            <configuration>
                <target>
                    <echo>Extracted git-Branch: ${git.branch}</echo>
                </target>
            </configuration>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
</plugin>

@NicolaSpreafico
Copy link
Author

I'm attaching you a sample project with all the plugins configured
testgit.zip

In order to use this, I created a simple git repository (only local) and set the HEAD to master (with only 1 commit).

To invoke the gcloud goal you can use "mvn appengine:deploy". The Maven goal will call GCloud SDK, so you need to have it installed in order to reach the point where the error occurs

If everything is configured correctly, you should see this Maven log

lug 11, 2017 8:34:42 AM com.google.cloud.tools.appengine.cloudsdk.CloudSdk logCommand
INFORMAZIONI: submitting command: C:\Users\Nicola\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\gcloud.cmd app deploy --no-promote --version ${git.branch}-2017-07-11 --project my-app-id
[INFO] GCLOUD: ERROR: (gcloud.app.deploy) argument --version/-v: Bad value [${git.branch}-2017-07-11]: May only contain lowercase letters, digits, and hyphens. Must begin and end with a letter or digit. Must not exceed 63 characters.

The output of the antrun-plugin is

main:
     [echo] Extracted git-Branch: master

@TheSnoozer
Copy link
Collaborator

Well this is somewhat really strange....Currently I can reproduce the problem but don't understand what it is caused by....

I thought it might be a Maven internal Problem where the @Parameter-Annotation is broken again and created a sample Maven-Project that uses the same stuff as the app-engine (https://github.com/GoogleCloudPlatform/app-maven-plugin/blob/master/pom.xml)

Just for future reference can be executed by:
mvn clean install && mvn clean package -Pdemo

Download project here:
SampleMavenProject.zip

I'll update once I have something more concrete....

@TheSnoozer
Copy link
Collaborator

Ok just as a follow up....I cloned the app-maven-plugin from git and introduced some debugging code to verify what is going on....

The Mojo-Class that is being used for mvn appengine:deploy and taking the version argument can be found here:
https://github.com/GoogleCloudPlatform/app-maven-plugin/blob/master/src/main/java/com/google/cloud/tools/maven/DeployMojo.java

In https://github.com/GoogleCloudPlatform/app-maven-plugin/blob/master/src/main/java/com/google/cloud/tools/maven/DeployMojo.java#L142 we have the getter-method that retrieves the parameter:

@Parameter(alias = "deploy.version", property = "app.deploy.version")
protected String version;

So far this is pretty much default stuff.

Now the interesting observation....when using the suggested command it doesn't seem to replace the Maven-project properties no matter what.

However when changing the plugin-Definition inside the pom.xml to the following:

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>appengine-maven-plugin</artifactId>
  <version>1.3.1</version>
  <configuration>
    <project>${app.id}</project>
    <deploy.version>${sample.generated}-${maven.version}-${app.version}</deploy.version>
    <deploy.promote>False</deploy.promote>
  </configuration>
  <executions>
    <execution>
      <id>deploy</id>
      <phase>install</phase>
      <goals>
        <goal>deploy</goal>
      </goals>
    </execution>
  </executions>
</plugin>

and executing mvn clean install the values and properties are getting replaced accordingly.

TL;DR,

When calling the Maven-Plugin via the Plugin's Prefix and goal mvn somePrefix:goal it doesn't resolve the variables correctly. When executing the plugin via the normal maven build cycle it is working as expected.

I'll report this to Maven and link as soon as I can remeber my password.
There is nothing i can do to fix this besides changing the way the plugin is being called.

@TheSnoozer
Copy link
Collaborator

TheSnoozer commented Jul 13, 2017

Maven Sample project to reproduce the issue:
SampleProjectV2.zip

mvn clean install && mvn clean package -> working
mvn clean install && mvn com.test.plugins:testPlugin:deployMojo -> broken
mvn clean install && mvn com.test.plugins:testPlugin:buildInjectPropertyMojo antrun:run com.test.plugins:testPlugin:deployMojo -> working

Maven Bug Report:
https://issues.apache.org/jira/browse/MNG-6260

@NicolaSpreafico
Copy link
Author

Any update on this issue?

@TheSnoozer
Copy link
Collaborator

TheSnoozer commented Sep 9, 2017

@NicolaSpreafico unfortunately there is no update on the Maven Issue.
Please use the suggested workaround outlined in
#287 (comment)

@NicolaSpreafico
Copy link
Author

Wih the suggested workaround seems to be working fine

<execution>
	<id>deploy</id>
	<phase>install</phase>
	<goals>
		<goal>deploy</goal>
	</goals>
</execution>

And launching

mvn clean install

This is not optimal because the Maven build is executed twice (one for the install goal and once again when the deploy goal is triggered) but while the Maven issue (hopefully) will be solved, I can live with that.

Here is the correct generated command
INFORMAZIONI: submitting command: gcloud.cmd app deploy appengine-staging\app.yaml appengine-staging\WEB-INF\appengine-generated\cron.yaml appengine-staging\WEB-INF\appengine-generated\queue.yaml --promote --version **develop-**20170909t135120

This workaround of yours seems to be working just fine with all the other plugins/configuration of the project, from a couple of tests I made is ok.

@TheSnoozer
Copy link
Collaborator

@NicolaSpreafico if the double build really turns out to be a problem try to to set your configuration to use the deploy-phase as well - AFAIK this should solve this. My configuration is just a suggestion.

Another workaround (basically based on #287 (comment)) would be using the following:
mvn pl.project13.maven:git-commit-id-plugin:revision appengine:deploy
This wouldn't require any changes but I feel this would be super annoying....

Unfortunately this bug also applies for other plugins and is not limited to the maven-git-commit-id-plugin.Since its a Maven-Bug (or at least how Maven currently works) I can't provide a fix for it.
Lets hope Maven fixes this soon ;-)

@NicolaSpreafico
Copy link
Author

Thank you for the additional details, this method is much easier.
I agree with you that if launched by hand this command can be annoying.

But in my specific case, I already using Eclipse launch profiles (because I'm using Eclipse IDE for development). This is an example of .launch file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.m2e.Maven2LaunchConfigurationType">
    <stringAttribute key="M2_GOALS" value="clean pl.project13.maven:git-commit-id-plugin:revision appengine:deploy" />
    <stringAttribute key="M2_PROFILES" value="development" />
    <stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${project_loc}" />
</launchConfiguration>

I'm using this profile due to a issue of m2e which is not properly handling the Maven profile for the environment (also are vary handy to launch goals), so I created 2 different launch profile, one for development and one for production.

At the end I simply added your suggestion for the revision goal into the GOALS configuration and I can now forget it because I will simply launch the profile for deploy.

For my case this second solution is much better that before, I now removed the execution configuration from the plugin and it seems to be working fine.

@TheSnoozer
Copy link
Collaborator

Thanks for the feedback! In this case it seems to be easier to have it configured within the Eclipse IDE as additional launch profile. If there anything not working with the suggested workaround please let me know.
Also worth to note:
mvn git-commit-id-plugin:revision appengine:deploy should work as well, but in case you configure it as a launch profile it doesn't really matter....

@NicolaSpreafico
Copy link
Author

Using your suggested configuration (I tried just as a test) I'm getting an error

[ERROR] No plugin found for prefix 'git-commit-id-plugin' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (.m2\repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]

This is strange because if I use the full package pl.project13.maven:git-commit-id-plugin:revision appengine:deploy works fine

@TheSnoozer
Copy link
Collaborator

Sorry just double checked. Based on the generated META-INF/maven/plugin.xml it should be
mvn git-commit-id:revision appengine:deploy

@NicolaSpreafico
Copy link
Author

Correct, now is working fine
<stringAttribute key="M2_GOALS" value="clean git-commit-id:revision appengine:deploy" />

I also removed the

              <executions>
                   <execution>
                       <id>get-the-git-infos</id>
                       <goals>
                           <goal>revision</goal>
                       </goals>
                   </execution>
               </executions>

node from plugin configuration in pom.xml considering that the revision goal is triggered by hand on the maven launch

@NicolaSpreafico
Copy link
Author

NicolaSpreafico commented Sep 10, 2017

Sorry, wrong button. I used "Close and Comment " instead of "Comment"

@mossad-zika
Copy link

any news?

@TheSnoozer
Copy link
Collaborator

Hi,
https://issues.apache.org/jira/browse/MNG-6260 is still open and in all honesty I don't think it ever will get fixed. I outlined several workarounds, but can't and won't change how maven is working under the hood (I personal stopped using maven for several reasons).

So in short, sorry if you still have this issue....

@NicolaSpreafico
Copy link
Author

Hello,
is there any update on this issue?

@TheSnoozer
Copy link
Collaborator

Hi, from my side there is no update and sadly I can't do anything about it.
As commented above this seems to be a maven issue and not a plugin issue itself. At least the Maven Ticket I created includes a sample plugin with bare minimum configuration that allows to reproduce the issue. Since no one from the maven team commented or is even bothered to look into it, I'm certainly not able to fix it....

Unfortunately I only can refer to the ugly workarounds:

  • see here: use mvn clean install (or similar) instead of mvn appengine:deploy
  • see here: use mvn pl.project13.maven:git-commit-id-plugin:revision appengine:deploy instead of mvn appengine:deploy

@NicolaSpreafico
Copy link
Author

Hi,
I can see there is a reply from Maven issue. Is there any useful information?

@TheSnoozer
Copy link
Collaborator

TheSnoozer commented Apr 25, 2019

Thanks for the alert!
I commented on the issue. As far as I understand the feedback the appengine:deploy with it's configuration is fully initialized before the property has changed. Essentially what this means is that the configuration is picking up the unchanged property e.g. ${git.branch} and the execution of the plugin then simply uses the configuration which reflects the outdated property.

Based on the comment I understand why this is issue is happening now, I asked if there is a workaround available (based on the comments it seems unlikely).....

Note for myself (possible dirty hack workaround):
Investigate if we can change the configuration of plugins....

for(Plugin p: project.getBuildPlugins()) {
          p.getConfiguration().TODOSOMETHING
}

see also
https://stackoverflow.com/a/130872/7890667
https://stackoverflow.com/a/4066483/7890667
https://stackoverflow.com/a/130872/7890667

@NicolaSpreafico
Copy link
Author

Thank you,
I read your reply on Maven issue and read the stackoverflow references you attached.

I understand that, while for this case the workaround is still appliable, with #413 there is no easy solution. As far I understood about all this case, this is something that need to be fixed at Maven level, not with third-parties plugins.

@TheSnoozer
Copy link
Collaborator

TheSnoozer commented Apr 25, 2019

that need to be fixed at Maven level, not with third-parties plugins

At the current stage I would say it certainly would be good and the right thing if it would be fixed at Maven level. However I honestly don't expect that to ever happen and if it happens I would expect it to only apply for a newer version of maven. Updating this plugin to this version would then potentially break the ability to use the plugin with older maven versions, which is something not desirable.

The stackoverflow links I posted are essentially links I found that potentially could used by third-parties plugins (like this plugin) to "fix" the problem. I currently didn't had the chance to perform further testing, so I currently can't say if this would be a feasonable approach. To the question if this would be ugly as hell, I would respond yes, but we are using maven after all...

I have some more time later or on the weekend to perform a better insight :-)

Edit:
It seems that the stackoverflow approach does not work:

    @Override
    protected void executeMojo() throws MojoExecutionException {
        getLog().warn("=====================================================================================");
        getLog().warn("executeMojo: " + getClass().getCanonicalName());
        project.getProperties().put("sample.generated", "Hello world!");
        for (final Plugin p:  project.getBuild().getPlugins()) { // project.getBuild().getPlugins() VS project.getBuildPlugins()
            getLog().warn("+++++++++++++++++++++++++ plugin: " + p.getArtifactId());
            Object rawConfig = p.getConfiguration();
            if (rawConfig != null) {
                getLog().warn("RAW: " + rawConfig);
                // getLog().warn("\t\t\t" + rawConfig.getClass());
                if (rawConfig instanceof org.codehaus.plexus.util.xml.Xpp3Dom) {
                    traverse((Xpp3Dom) rawConfig);
                }
                getLog().warn("UPDATED: " + p.getConfiguration());
            }
            p.setConfiguration(rawConfig);

        }
        getLog().warn("=====================================================================================");
    }

    private void traverse(Xpp3Dom root){ // @Nullable
        if (root != null && root.getChildren() != null) {
            for (Xpp3Dom child : root.getChildren()) {
                // getLog().warn("\t\t\t name=" + child.getName() + " / value = " + child.getValue());
                if (child.getValue() != null) {
                    child.setValue(child.getValue().replaceAll("\\$\\{sample.generated\\}", "Hello world!"));
                }
                traverse(child);
            }
        }
    }

reports

$ mvn clean install -e && mvn com.test.plugins:testPlugin:deployMojo -e
.....
[WARNING] +++++++++++++++++++++++++ plugin: testPlugin
[WARNING] RAW: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <enableJarSplitting>true</enableJarSplitting>
  <some.exampleParameter>${sample.generated}</some.exampleParameter>
</configuration>
[WARNING] UPDATED: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <enableJarSplitting>true</enableJarSplitting>
  <some.exampleParameter>Hello world!</some.exampleParameter>
</configuration>
....
[INFO] --- testPlugin:0.1:deployMojo (default-cli) @ testPlugin ---
[WARNING] =====================================================================================
[WARNING] executeMojo: com.test.plugins.testPlugin.buildInfo.DeployMojo
[WARNING] exampleParameter:null
[WARNING] =====================================================================================

@NicolaSpreafico
Copy link
Author

Thank you,
so, just to be sure, at the moment there is no workaround for having the git.branch name inside SonarQube version?

@TheSnoozer
Copy link
Collaborator

Please refer to #413 (comment) for the difference between the SonarQube issue and this one.

Since there is not much I can do to fix this (as per comment in the maven issue) I only can refer to the available workaround or suggest to open a ticket with the appengine plugin to have some sort of functionality that makes such behaviour possible.

Sadly from the perspective of the plugin I nothing left besides closing this as Can't fix :-(

@TheSnoozer TheSnoozer added this to the 3.0 milestone Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants