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

Wrong properties values when building under Hudson #370

Closed
pauloneves opened this issue Jul 5, 2018 · 2 comments
Closed

Wrong properties values when building under Hudson #370

pauloneves opened this issue Jul 5, 2018 · 2 comments

Comments

@pauloneves
Copy link

The plugin is generating wrong values when running under Hudson. It works fine when I run it in my local machine.

It looks like it is related to the issue #325

Below is the generated git.properties with some comments.

#Generated by Git-Commit-Id-Plugin
#Thu Jul 05 19:58:18 BRT 2018
git.branch=43bb4ef9f75d2c88217ff3aa27288b240fdc256a #not the branch, but a commit hash
git.build.host=correct
git.build.time=2018-07-05T19\:38\:57-0300
git.build.version=1.4.96-SNAPSHOT #correct from maven
git.closest.tag.commit.count=0 #always zero
git.closest.tag.name=hudson-<my job name>-<build  number> #always wrong
git.commit.id=ad684aaa425b293046eca3ca73bd199d80b9fc62 #different from above
git.commit.id.abbrev=ad684aa
git.commit.id.describe=hudson-<my job name>-<build  number> # as above
git.commit.id.describe-short=hudson-<my job name>-<build  number> #as above
git.commit.time=2018-07-05T19\:02\:04-0300
git.dirty=false
git.remote.origin.url=correct
git.tags=hudson-<my job name>-<build  number> # as above

First error:
git.branch is the commit hash of the HEAD of the branch. In my job the branch to build is configured as ** (to build all the branches). If I fix a branch in this parameter it displays the branch name correctly.

All these parameters are incorrect with the same value:
git.closest.tag, git.closest.tag.name, git.commit.id.describe

They have the exact same value that is in the Hudson env variable BUILD_TAG, that is: a fixed prefix hudson-, concatenated with the job name + '-' + the build number.

I'm using a very old Hudson version.

Below is my plugin configuration. I tried with as true and false and got the same (wrong) result.

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

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

                    <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>

                    <excludeProperties>
                      <excludeProperty>git.*.user.*</excludeProperty>
                      <excludeProperty>git.commit.message.*</excludeProperty>
                    </excludeProperties>

                    <useNativeGit>true</useNativeGit>
                    <evaluateOnCommit>HEAD</evaluateOnCommit>
                    <verbose>true</verbose>
                </configuration>

            </plugin>

It is a multimodule project, and this configuration is in the pom parent. All submodules generate their git.properties file.

I have the verbose output here and can send it by email if you wish. I don't want to post here some of my company info.

@TheSnoozer
Copy link
Collaborator

TheSnoozer commented Jul 7, 2018

Hi,
thanks for reporting your issue here.
Let me try to elaborate on each of the reported issues.
1.

git.branch is the commit hash of the HEAD of the branch

CI builds are usually done in detached HEAD state (https://www.git-tower.com/learn/git/faq/detached-head-when-checkout-commit) and thus essentially make it impossible to know on what branch we are.The workaround trick that this plugin is doing to get the branch is to extract environment variables exposed by the CI-Build.

In my job the branch to build is configured as ** (to build all the branches). If I fix a branch in this parameter it displays the branch name correctly.

Does the configuration of ** (to build all the branches) launches a single build that builds through all branches? Or is it just that hudson "listens" to changes on all branches and builds them in a single build once it detected a change? Not sure how Hudson behaves here...maybe it would help in specific if you could elaborate what type of setup you have so I could get a better understanding (single job with just the ** branch config? pipeline configuration?

All these parameters are incorrect with the same value:
git.closest.tag, git.closest.tag.name, git.commit.id.describe

They have the exact same value that is in the Hudson env variable BUILD_TAG, that is: a fixed prefix hudson-, concatenated with the job name + '-' + the build number.

That sounds like Hudson is creating tags for each build and thus altering the local checkout of the clone. There should be a configuration (somewhere) in the job that controls if Hudson should create tags for each build (similar to http://www.benhallbenhall.com/2013/03/hudson-jenkins-create-git-tags-branches-automatically/).
By the looks I would tend to say this is a misconfiguration and the plugin is getting the 'right' information, that have been injected at a wrong place. It should be easy to login into hudson via SSH, go to the directory where the checkout is, and simply do a git describe --long. I would suspect this returns similar tag names as the plugin (if so it is a job misconfiguration)

It is a multimodule project, and this configuration is in the pom parent. All submodules generate their git.properties file.

You may (or may not) want to add <runOnlyOnce>true</runOnlyOnce> to the plugin configuration.

From the Readme:

Use with caution!

In a multi-module build, only run once. This means that the plugins effects will only execute once, for the parent project.
This probably won't "do the right thing" if your project has more than one git repository.

Important: If you're using generateGitPropertiesFile, setting runOnlyOnce will make the plugin
only generate the file in the directory where you started your build (!).

Important: Please note that the git-commit-id-plugin also has an option to skip pom project (<packaging>pom</packaging>).
If you plan to use the runOnlyOnce option alongside with an aggregator pom you may want to set <skipPoms>false</skipPoms>.

The git.* maven properties are available in all modules.
Default value is false.

I'm using a very old Hudson version.

Whats the version you are using? :-)

@TheSnoozer
Copy link
Collaborator

I'm closing this. since I don't see a particular issue within the plugin.
If you provide a pointer to a specif problem I'd be happy to look into it.

@TheSnoozer TheSnoozer added this to the 3.0 milestone May 1, 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

2 participants