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 <[email protected]> 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 <[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/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 [email protected]. 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.
