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=${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/32256296-87b8-40cf-8a6b-c27c193f2d5a%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/32256296-87b8-40cf-8a6b-c27c193f2d5a%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/CAO49JtFg_wAZF49Vi0-uAhsqOXx3dzqrbUY%3DwBEBxRNHX5O1KQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
