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]> 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]> > 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]> 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/CAO49JtHckAhsUXVuM9-kYb4xV%2BTJu9-vgEDvZ%2BydwkGSVfCjDg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
