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) 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) Running hudson.plugins.git.JGitSCMTriggerRemotePollTest On Tuesday, January 5, 2016 at 3:55:01 PM UTC-7, Mark Waite wrote: > > 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 <https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/1031/> 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 > > On Tue, Jan 5, 2016 at 3:39 PM Michael Giroux <[email protected] > <javascript:>> wrote: > >> 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? >> >> >> On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite wrote: >> >>> 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 >>> >>> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <[email protected]> wrote: >>> >> 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 >>>> >>>> >>>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite wrote: >>>> >>>>> 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 >>>>> >>>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux <[email protected]> >>>>> wrote: >>>>> >>>> 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? >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark Waite wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> On Wed, Dec 30, 2015 at 11:41 AM Michael Giroux <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, December 30, 2015 at 11:22:33 AM UTC-7, Michael >>>>>>>> Giroux wrote: >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> On Wednesday, December 30, 2015 at 10:34:59 AM UTC-7, Mark Waite >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 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()); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, Michael >>>>>>>>>>> Giroux wrote: >>>>>>>>>>>> >>>>>>>>>>>> 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) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, Mark Waite >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, Mark >>>>>>>>>>>>>> Waite wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tuesday, December 29, 2015 at 10:03:25 AM UTC-7, Michael >>>>>>>>>>>>>>>> Giroux wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 [email protected] >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/37f6bc2d-d43e-44ff-a877-c525e5007842%40googlegroups.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/37f6bc2d-d43e-44ff-a877-c525e5007842%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/cbaf764b-e3d9-480e-980c-23b772fd4a43%40googlegroups.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/cbaf764b-e3d9-480e-980c-23b772fd4a43%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>> . >>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>> 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 [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/25050720-c0f3-465d-bc83-4d191c1c7bf6%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/25050720-c0f3-465d-bc83-4d191c1c7bf6%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> 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 [email protected]. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/0cf5698d-3060-49db-b75f-72c5d71d5b7b%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/0cf5698d-3060-49db-b75f-72c5d71d5b7b%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>>> 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 [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/jenkinsci-users/5815a292-6fa3-4c2f-838f-c95c53cddbac%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/5815a292-6fa3-4c2f-838f-c95c53cddbac%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-users/32256296-87b8-40cf-8a6b-c27c193f2d5a%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-users/32256296-87b8-40cf-8a6b-c27c193f2d5a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/5cb20287-5b71-4e86-9077-ac71ec319b91%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/5cb20287-5b71-4e86-9077-ac71ec319b91%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3a361e77-b22b-403a-8428-962c6cd7e3f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
