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=${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 >>> <https://groups.google.com/d/msgid/jenkinsci-users/0cf5698d-3060-49db-b75f-72c5d71d5b7b%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/5815a292-6fa3-4c2f-838f-c95c53cddbac%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/5815a292-6fa3-4c2f-838f-c95c53cddbac%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/CAO49JtF93kZwK_0mZqhtHP_x4RJFM1NxmmhnMnxhjtq%3DVCLxkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
