I use various versions of maven, including Maven 3.2.5, and the latest versions of Oracle Java 7 and Oracle Java 8 on the platforms where I compile and run. I also use OpenJDK 7 and OpenJDK 8 on at least a few of the platforms.
I also built and tested on FreeBSD 10.1 using OpenJDK 7. That's the closest I can approximate to a MacOS machine. It fails with a hundred or more test failures, but not with the message you're seeing. I built and tested on FreeBSD 10.1 using OpenJDK 8. It also fails with a hundred or more test failures, but not the message you're seeing. I am able to run slave agents on FreeBSD, and the git plugin and git client plugin are able to clone repositories, but I can't compile and test successfully on FreeBSD with either OpenJDK 7 or OpenJDK 8. I think the problem you're seeing is either platform specific (like my FreeBSD problem), or environment and configuration specific. Unfortunately, I don't have any way to do further diagnosis. You might check with Craig Rodrigues on this mailing list. I believe he's a FreeBSD developer. I don't think I've ever seen a Darwin developer on the list. Mark Waite On Tue, Jan 5, 2016 at 7:02 PM Michael Giroux <mlgir...@gmail.com> wrote: > Mac OS should not matter. Maven is Java, and Java is platform neutral (in > theory), but maven version may be of interest. > > What is your specific build environment? > > > > On Tuesday, January 5, 2016 at 6:02:56 PM UTC-7, Mark Waite wrote: > >> 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 <mlgi...@gmail.com> 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 <mlgi...@gmail.com> >>>>> 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 <mlgi...@gmail.com> >>>>>>> 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 <mlgi...@gmail.com> >>>>>>>>> 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 < >>>>>>>>>>> mlgi...@gmail.com> 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 < >>>>>>>>>>>>>> mlgi...@gmail.com> 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 < >>>>>>>>>>>>>>>>> mlgi...@gmail.com> 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 < >>>>>>>>>>>>>>>>>>> mlgi...@gmail.com> 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 jenkinsci-use...@googlegroups.com. >> >> >>> 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 jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/78815edf-b1a7-478a-bda1-6b722400fb55%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/78815edf-b1a7-478a-bda1-6b722400fb55%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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFAR%2BNRrJCUV%3DjgkqWVfnzKjd7SJOcDi7Q%2Bdo1%3DeZfrKA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
