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=${GIT_BRANCH/*\//}
>>>>>>>>> git rev-parse --quiet --verify ${LOCAL_GIT_BRANCH} && git branch 
>>>>>>>>> -D ${LOCAL_GIT_BRANCH}
>>>>>>>>> git checkout -b ${LOCAL_GIT_BRANCH} ${GIT_COMMIT}
>>>>>>>>>
>>>>>>>>> With this in place, the build checks the code out to a local 
>>>>>>>>> branch with the same name as the remote branch allowing the maven 
>>>>>>>>> release:prepare goal to push changes to the branch that is being 
>>>>>>>>> build.
>>>>>>>>>
>>>>>>>>> NOTE that we have tried to configure the "checkout to local 
>>>>>>>>> branch" using the property that is configured by the Git ($BRANCH) 
>>>>>>>>> but that 
>>>>>>>>> results in local branch names of "origin/master", 
>>>>>>>>> "origin/some_branch", 
>>>>>>>>> ...  This results in release:prepare doing pushes as "git push ... 
>>>>>>>>> origin/some_branch:origin/some_branch" which results in a new remote 
>>>>>>>>> branch 
>>>>>>>>> named "origin/some_branch"  We have seen repos with branches named 
>>>>>>>>> "origin/master".  As a result, the desired branch is not updated, and 
>>>>>>>>> a new 
>>>>>>>>> branch is created.
>>>>>>>>>
>>>>>>>>> QUESTION/SUGGESTION/...
>>>>>>>>> It would be nice to have an option in the Git plugin to "checkout 
>>>>>>>>> to local branch" that derives the local branch name from the remote 
>>>>>>>>> branch 
>>>>>>>>> name, without having to add our pre-build step.  Thus, if I select 
>>>>>>>>> "origin/some_branch" from the Git parameter, I could checkout to 
>>>>>>>>> local 
>>>>>>>>> branch using the Git Parameter $BRANCH which would resolve to 
>>>>>>>>> "some_branch" 
>>>>>>>>> sans the "origin/" prefix.
>>>>>>>>>
>>>>>>>>> Steps to Reproduce:
>>>>>>>>> 1. configure a parameterized job with a git parameter using 
>>>>>>>>> "BRANCH" as the parameter name
>>>>>>>>> 2. configure the Git scm additional behavour to checkout to local 
>>>>>>>>> branch "$BRANCH"
>>>>>>>>> 3. configure job with as a maven release.
>>>>>>>>> 4. perform a maven releae, selecting one of the branches from the 
>>>>>>>>> list of Git Parameter options.
>>>>>>>>> 5. observe console output to examine the "git push" commands 
>>>>>>>>> generated by the release:prepare goal.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>> 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/37f6bc2d-d43e-44ff-a877-c525e5007842%40googlegroups.com
>>>>>>>>  
>>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/37f6bc2d-d43e-44ff-a877-c525e5007842%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/cbaf764b-e3d9-480e-980c-23b772fd4a43%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/cbaf764b-e3d9-480e-980c-23b772fd4a43%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/25050720-c0f3-465d-bc83-4d191c1c7bf6%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/25050720-c0f3-465d-bc83-4d191c1c7bf6%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/0cf5698d-3060-49db-b75f-72c5d71d5b7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to