That's a very strange message. The only reference I could find to that message was a wiki article from 2011. See https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor in case that gives you any help.
I see that you're running on MacOS, and I don't have a MacOS machine in my mix of development and test environments, so there may be something specific to the Mac. Mark Waite On Tue, Jan 5, 2016 at 4:29 PM Michael Giroux <[email protected]> wrote: > Attaching build.log for complete build result. shows maven version and > java versions at head of file. > > > On Tuesday, January 5, 2016 at 4:25:25 PM UTC-7, Michael Giroux wrote: >> >> 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]> 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=${GI >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- > 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/b1636c11-3a56-41ed-ba5d-547dae02292a%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/b1636c11-3a56-41ed-ba5d-547dae02292a%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/CAO49JtFRw%3Du4R2UYv3z3h_YPm%2BvJucUyRY71TdO0SvmxR%2BEwjw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
