Jenkins Git Plugin and Maven Release Builds

Michael Giroux

unread,

Dec 29, 2015, 12:03:25 PM12/29/15

to Jenkins Users

Using Jenkins 1.609.3, Git plugin 2.4.0.

We have configured most of our jobs to allow jobs to be initiated by the Stash Webhook to Jenkins. To allow developers to manually initiate a build of any branch, the jobs use the Git Parameter to set a BRANCH variable.

Using this configuration, the Git Parameter is configured to set "**" as the default branch to build. This allows the Stash Webhook to initiate a build of any branch. In order to allow the job to perform a maven release, we have configured the Git SCM to checkout to local branch "master". This all works well as long as we are not doing a maven release, or when we do a maven release on the master branch. The strategy breaks down if the developer attempts a maven release on another branch when the maven release:prepare goal tries to push pom updates. Note that the maven release plugin uses the current local branch in the push as "git push url localBranch:localBranch" As a result, when the build is for "some_branch" which has been checked out to local branch "master" we get an error on "git push ... master:master" because the remote "master" is not in sync with the local. No surprises here since the local "master" is actually "some_branch".

To resolve this, we have deleted the "checkout to local branch" additional action, and added a pre-build step that does the following:'

# checkout to a local branch using the remote branch name

LOCAL_GIT_BRANCH=${GIT_BRANCH/*\//}

git rev-parse --quiet --verify ${LOCAL_GIT_BRANCH} && git branch -D ${LOCAL_GIT_BRANCH}

git checkout -b ${LOCAL_GIT_BRANCH} ${GIT_COMMIT}

With this in place, the build checks the code out to a local branch with the same name as the remote branch allowing the maven release:prepare goal to push changes to the branch that is being build.

NOTE that we have tried to configure the "checkout to local branch" using the property that is configured by the Git ($BRANCH) but that results in local branch names of "origin/master", "origin/some_branch", ... This results in release:prepare doing pushes as "git push ... origin/some_branch:origin/some_branch" which results in a new remote branch named "origin/some_branch" We have seen repos with branches named "origin/master". As a result, the desired branch is not updated, and a new branch is created.

QUESTION/SUGGESTION/...

It would be nice to have an option in the Git plugin to "checkout to local branch" that derives the local branch name from the remote branch name, without having to add our pre-build step. Thus, if I select "origin/some_branch" from the Git parameter, I could checkout to local branch using the Git Parameter $BRANCH which would resolve to "some_branch" sans the "origin/" prefix.

Steps to Reproduce:

1. configure a parameterized job with a git parameter using "BRANCH" as the parameter name

2. configure the Git scm additional behavour to checkout to local branch "$BRANCH"

3. configure job with as a maven release.

4. perform a maven releae, selecting one of the branches from the list of Git Parameter options.

5. observe console output to examine the "git push" commands generated by the release:prepare goal.

Mark Waite

unread,

Dec 29, 2015, 9:14:58 PM12/29/15

to Jenkins Users

Have you tried "Branch to build" as master rather than origin/master?

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/eeeff5a0-a7c8-4252-bbec-33168968a14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Giroux

unread,

Dec 30, 2015, 12:36:32 AM12/30/15

to Jenkins Users

Yes.

The issue I'm describing is a result of using the Git Parameter plugin which allows the user to select a branch, + the Git plugin which allows configuration of the branch to build and the local branch name, + maven release plugin which relies on local branch name for push to remote + Stash Webhook to Jenkins with triggers a build of any arbitrary branch.

I will admit that one solution is to create two jobs in Jenkins to allow building of any arbitrary branch as triggered by the Stash web hook for jenkins, and a second job that is configured to build a branch specified by user supplied parameter values.

The problem occurs when when attempting to configure a single jenkins build that allows for manual specification of branch via the Git parameter, and builds kicked off by the Stash web hook to jenkins.

1. to allow the jenkins web hook to initiate a build, it is necessary to configure the build to build any branch (leaving branch to build as blank).

2. to allow a maven release to build, you MUST specify a local branch name. Otherwise, the push to stash fails the build does not have a local branch name.

3. To meet condittion #1, the default value for the Git parameter must be "**" so that the branch to build is ANY (** or empty)

So basically, the issue is that if a build is configured to build any branch, and also has maven release configured, you need some way to get the code checked out to a local branch (additional behaviors) with the same name as the branch being built, and there is currently no way to do that.

I tried to put "${GIT_BRANCH/*\//}" into the "checkout to local branch" but this did not work. It seems this field does not resolve environment variable references using full bash variable reference notation. Perhaps this is the solution. Extend the "checkout to local branch" to provide full bash resolution of the variable name.

Mark Waite

unread,

Dec 30, 2015, 12:47:14 AM12/30/15

to Jenkins Users

There is a pending pull request to the git plugin which provides a new environment variable, GIT_SHORT_BRANCH_NAME. The semantics of that proposed environment variable are not quite what you're describing, but you might review the pull request to see if it is close enough for your use case. See https://github.com/jenkinsci/git-plugin/pull/347 and https://github.com/jenkinsci/git-plugin/pull/304 for two different possibilities.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/37f6bc2d-d43e-44ff-a877-c525e5007842%40googlegroups.com.

Michael Giroux

unread,

Dec 30, 2015, 11:21:05 AM12/30/15

to Jenkins Users

Mark, I'm taking a look at the two pull requests. I cloned the repo so I can view code in Eclipse, but I'm getting compile errors in GitSCMTest.java:

Description Resource Path Location Type

The method configRoundtrip(FreeStyleProject) is ambiguous for the type GitSCMTest GitSCMTest.java /git/src/test/java/hudson/plugins/git line 1206 Java Problem

Suggestions?

Michael

Mark Waite

unread,

Dec 30, 2015, 11:53:36 AM12/30/15

to Jenkins Users

Don't attempt to evaluate the two pull requests in the same repository. They are two different ideas that might meet your need. I suspect that one or the other will eventually be merged, but not both.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cbaf764b-e3d9-480e-980c-23b772fd4a43%40googlegroups.com.

Michael Giroux

unread,

Dec 30, 2015, 12:29:37 PM12/30/15

to Jenkins Users

Not making any changes to code, just trying to examine primary project source to understand what is being changed in the PRs.

I cloned the primary git repo from https://github.com/jenkinsci/git-plugin.git so I could get some context for the PRs which show only the code being changed. Getting compile errors on unmodified project.

Eclipse version 4.5 (Mars), JDK 1.8.0 (also tried JDK 1.7.0)

Michael Giroux

unread,

Dec 30, 2015, 12:30:55 PM12/30/15

to Jenkins Users

BTW, the following patch resolves my compile errors, but not sure if the cast to (Item) is the best choice.

diff --git a/src/test/java/hudson/plugins/git/GitSCMTest.java b/src/test/java/hudson/plugins/git/GitSCMTest.java

index 3a14b10..a39e60c 100644

--- a/src/test/java/hudson/plugins/git/GitSCMTest.java

+++ b/src/test/java/hudson/plugins/git/GitSCMTest.java

@@ -1203,7 +1203,7 @@

false, Collections.<SubmoduleConfig>emptyList(),

browser, null, null);

p.setScm(scm);

- configRoundtrip(p);

+ configRoundtrip((Item)p);

assertEqualDataBoundBeans(scm,p.getScm());

assertEquals("Wrong key", "git " + url, scm.getKey());

}

@@ -1215,7 +1215,7 @@

FreeStyleProject p = createFreeStyleProject();

GitSCM scm = new GitSCM("https://github.com/jenkinsci/jenkins");

p.setScm(scm);

- configRoundtrip(p);

+ configRoundtrip((Item)p);

assertEqualDataBoundBeans(scm,p.getScm());

Mark Waite

unread,

Dec 30, 2015, 12:34:59 PM12/30/15

to Jenkins Users

https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ (and my internal Jenkins server inside my firewall) confirm that the code on the master branch compiles correctly from the maven command line.

I run my debugger from Netbeans (rather than Eclipse) and can confirm that it compiles and runs from Netbeans as well. I don't use Eclipse, so I'm not much help wiht Eclipse specific failures.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/25050720-c0f3-465d-bc83-4d191c1c7bf6%40googlegroups.com.

Michael Giroux

unread,

Dec 30, 2015, 1:22:33 PM12/30/15

to Jenkins Users

Thanks Mark. Command line build runs fine w/o compile errors. For your reference, this is a known Eclipse issue bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=369592.

Michael Giroux

unread,

Dec 30, 2015, 3:41:32 PM12/30/15

to Jenkins Users

Mark, I wonder if one of the issues I have is actually a defect in the Git Parameter plugin. Specifically, the values set by the Git Parameter plugin include the "origin/" prefix. When this is used as the value for checkout to local branch, AND the build is a maven release, we end up with a new branch in Stash "origin/master" (should be simply master) or "origin/some_other_branch". It seems that normal builds run just fine, but release builds result in pushes back to Git and here is where the branch names get messed up.

Should I be asking the Git Parameter plugin developers to strip the leading "origin/" from the branch names that are assigned to the parameter?

Michael

Mark Waite

unread,

Dec 30, 2015, 5:12:49 PM12/30/15

to Jenkins Users

Could do that as well, though the git parameter plugin is technically correct. It is showing the branch to be built, and the branch to be built truly is "origin/master", since there is no local master branch tracking the remote branch.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0cf5698d-3060-49db-b75f-72c5d71d5b7b%40googlegroups.com.

Michael Giroux

unread,

Dec 31, 2015, 10:07:39 AM12/31/15

to Jenkins Users

Accepting that the Git Parameter plugin is technically correct, lets get back to the maven release build issue.

1. to do a maven release, we MUST configure the "checkout to local branch" option, or define a pre build step to do a git checkout into a local branch.

2. the local branch name MUST be the effective name on the remote (sans origin/) to allow the maven release:prepare to push the pom changes to the correct branch.

3. we currently can not use the value from the Git Parameter plugin because that includes the "origin/" prefix resulting in a new branch created on the remote git repo.

I'm not really sure where the option belongs, but to support doing a maven release on a branch specified by the Git Parameter plugin we need a clean way to get the code checked out into the correct local branch.

The Git plugin could provide an option to derive local branch name, or the Git Parameter plugin could define an additional parameter containing the effective branch name. I'm not sure which is best approach. I suspect that the Git plugin should be able to operate whether the Git Parameter plugin has been configured or not, so I lean toward an option in Git plugin to "checkout to local branch" that ends up with the required local branch name, but there may be a more appropriate approach.

What is the next step?

Mark Waite

unread,

Dec 31, 2015, 10:41:53 AM12/31/15

to Jenkins Users

I think your logic is very reasonable. The git plugin seems like the right place to do that. Since the need is to reference a substring of the current GIT_BRANCH value within the context of a Jenkins job, it seems like an addition to the token macro keywords allowed on GIT_BRANCH might meet your need.

You might refer to https://issues.jenkins-ci.org/browse/JENKINS-25465 for a discussion of the fullName=false parameter to GIT_BRANCH, in case that will already handle your case.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5815a292-6fa3-4c2f-838f-c95c53cddbac%40googlegroups.com.

Michael Giroux

unread,

Dec 31, 2015, 1:54:39 PM12/31/15

to Jenkins Users

I looked at JERKINS-25465 and it looked interesting, so I tried to configure the "checkout to local branch" as ${GIT_BRANCH,fullName=false}. This resulted in a checkout to a branch named exactly that, with no expansion.

I have Git plugin version 2.4.1 (and all dependent plugins) installed.

I do not see anything in the Git Plugin documentation that references the ,fullName qualifier on the expansion.

So I'm guessing I'm missing something here. where exactly can this syntax be used, and where is it documented? Should I be able to use this in the additional behaviors?

Michael

Michael Giroux

unread,

Jan 5, 2016, 1:47:27 PM1/5/16

to Jenkins Users

Mark,

I think there may be a simple solution that can be implemented in the Git plugin. If the job is configured with additional behavior "checkout to local branch" AND the local branch name is left blank, then the Git plugin could do a checkout of the configured remote branch sans "origin/". I think this allows for current behavior while also allowing maven release builds to run.

Michael

Mark Waite

unread,

Jan 5, 2016, 2:59:55 PM1/5/16

to Jenkins Users

That is am interesting idea. Giving a semantic meaning to am empty field should not alert behavior for non-empty fields. Will you be coding it?

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/32256296-87b8-40cf-8a6b-c27c193f2d5a%40googlegroups.com.

Michael Giroux

unread,

Jan 5, 2016, 3:41:18 PM1/5/16

to Jenkins Users

Have not contributed in past, but willing to take a cut at it. Off to look at it.

As mentioned in a prior post, I've forked the project and ran into a minor issue with builds inside Eclipse. I filed a bug at Eclipse. https://bugs.eclipse.org/bugs/show_bug.cgi?id=485066

Michael

Message has been deleted

Michael Giroux

unread,

Jan 5, 2016, 5:39:30 PM1/5/16

to Jenkins Users

Before I start making changes, I'm building from master and getting test failures. Is there a document that explains additional environment setup needed to work on plugins?

Mark Waite

unread,

Jan 5, 2016, 5:55:01 PM1/5/16

to Jenkins Users

I'm interested in the test failures you're seeing, since there are currently no test failures on the Cloudbees execution of the automated tests on the master branch, and there were only three random failures on my execution of the automated tests on CentOS 6, CentOS 7, Debian 6, Debian 7, Debian 8, Windows 7, and Windows 10, with Java 7 and Java 8.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5cb20287-5b71-4e86-9077-ac71ec319b91%40googlegroups.com.

Michael Giroux

unread,

Jan 5, 2016, 6:25:25 PM1/5/16

to Jenkins Users

I'm running a build now, will attach console output when tests complete. Here is an example of a failure:

java.lang.AssertionError: class hudson.plugins.git.util.DefaultBuildChooser is missing its descriptor

at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1165)

at hudson.plugins.git.util.BuildChooser.getDescriptor(BuildChooser.java:142)

at hudson.plugins.git.util.BuildChooser.getDisplayName(BuildChooser.java:45)

at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:555)

at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529)

at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384)

at hudson.scm.SCM.poll(SCM.java:401)

at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1450)

at hudson.model.AbstractProject._poll(AbstractProject.java:1421)

at hudson.model.AbstractProject.poll(AbstractProject.java:1332)

at hudson.plugins.git.SCMTriggerTest.check(SCMTriggerTest.java:271)

at hudson.plugins.git.SCMTriggerTest.testCommitAsBranchSpec_feature4_sha1(SCMTriggerTest.java:206)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:486)

at org.junit.rules.RunRules.evaluate(RunRules.java:20)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)

at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)

at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)

at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)

at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)

at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

testCommitAsBranchSpec_feature4_branchName(hudson.plugins.git.JGitSCMTriggerLocalPollTest) Time elapsed: 10.183 sec <<< FAILURE!

java.lang.AssertionError: class hudson.plugins.git.util.DefaultBuildChooser is missing its descriptor

at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1165)

at hudson.plugins.git.util.BuildChooser.getDescriptor(BuildChooser.java:142)

at hudson.plugins.git.util.BuildChooser.getDisplayName(BuildChooser.java:45)

at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:555)

at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529)

at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384)

at hudson.scm.SCM.poll(SCM.java:401)

at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1450)

at hudson.model.AbstractProject._poll(AbstractProject.java:1421)

at hudson.model.AbstractProject.poll(AbstractProject.java:1332)

at hudson.plugins.git.SCMTriggerTest.check(SCMTriggerTest.java:271)

at hudson.plugins.git.SCMTriggerTest.testCommitAsBranchSpec_feature4_branchName(SCMTriggerTest.java:214)