Really appreciate the suggestions. To eliminate eclipse, I cloned https://github.com/jenkinsci/git-plugin.git to a new directory and built with maven. Same issue. Wonder if this is caused by my version of OS X (10.11.2) El Capitan. I'm going to check the maven groups.
On Wednesday, January 6, 2016 at 12:25:48 PM UTC-7, Vincent Latombe wrote: > > If you use Eclipse, make sure you do a clean build in maven. Not doing so > will result in odd failures with all things related to annotation > processing, such as the error message you are getting. > > Vincent > > 2016-01-06 17:22 GMT+01:00 Mark Waite <[email protected] <javascript:>> > : > >> I had a friend at the office compile the master branch of the git plugin >> on his MacOS machine with maven 3.3.1 and Java 1.8.0_60. No test failures >> for him either. I truly don't know what's different about your environment >> that causes the tests to fail. >> >> Mark Waite >> >> On Tue, Jan 5, 2016 at 9:01 PM Mark Waite <[email protected] >> <javascript:>> wrote: >> >>> It may be that you're seeing a slightly different variation on MacOS of >>> what I'm seeing on FreeBSD. On FreeBSD, it appears the tests fail due to >>> the Jenkins version on which the git plugin is based. >>> >>> I maintain a working branch (for compatibility testing) on >>> https://github.com/MarkEWaite/git-plugin/tree/ongoing/latest-jenkins-lts . >>> That branch compiles and passes all tests on FreeBSD 10.1 with OpenJDK 8. >>> It is the same content as the git plugin master branch, plus an update to >>> the pom.xml to depend on the latest Jenkins long term support release. I >>> believe it also includes one other relatively minor change required in the >>> newer Jenkins version. >>> >>> You might try that same branch for yourself. >>> >>> Mark Waite >>> >>> On Tue, Jan 5, 2016 at 8:22 PM Mark Waite <[email protected] >>> <javascript:>> wrote: >>> >>>> 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] >>>> <javascript:>> 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. T >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- 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/e021aee2-db95-46fb-9654-162df8a1f72e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
