By default, the git plugin checks out a "detached head" rather than
checking out to a named local branch.  If you add the "Additional
Behaviours" to do a "Checkout to specific local branch" and assign it the
value "**", then the plugin will attempt to checkout to a local branch
which matches the branch name from the source repository.

That capability was added in git plugin 2.4.3 as the implementation of
https://issues.jenkins-ci.org/browse/JENKINS-33202 .

Mark Waite

On Mon, Jun 13, 2016 at 5:37 AM Jerry Steele <[email protected]>
wrote:

> Thanks for the info re: In-process script approval, that worked :)
>
> @Mark, I'm pretty sure that I need to glean info about the branch from the
> current build, because this has to be passed as an argument to my build
> tool. I was hoping that this could be done via an environment variable, but
> this doesn't seem to be possible.
>
> I tried the method here
> <http://stackoverflow.com/questions/35554983/git-variables-in-jenkins-workflow-plugin>,
> but confusingly, that threw an error like this:
>
> [multibranch test] Running shell script
> + git rev-parse --abbrev-ref HEAD
> fatal: ambiguous argument 'HEAD': unknown revision or path not in the working 
> tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
>
>
> ...
>
>
> ...which seems to be an issue with git itself.
>
> Is there a tried and tested way of getting environment variables like this
> into the build process?
>
> Thanks
>
> Jerry
>
> On Monday, 13 June 2016 12:00:22 UTC+1, Mark Waite wrote:
>
>> For the multi-branch development work I've been doing, it has been better
>> to avoid placing branch information inside the Jenkinsfile.  The problem I
>> had was that most of my branches are short-lived.  They exist long enough
>> to allow me to validate a pull request, but then they are merged to the
>> master branch.  If I place branch information inside the Jenkinsfile on
>> that short-lived branch, then the branch information from the short-lived
>> evaluation branch would be merged into the master branch when the proposed
>> change is merged into the master branch.
>>
>> Instead of placing branch information inside the Jenkinsfile, I think you
>> want to use the "checkout scm" pipeline step like Liam Newman did in
>> https://github.com/jenkinsci/git-plugin/blob/master/Jenkinsfile .  That
>> same Jenkinsfile exists on other branches in that repository, and each
>> branch that has a Jenkinsfile is now evaluated from a multi-branch pipeline
>> project (as in
>> https://github.com/jenkinsci/git-plugin/blob/2.5.0-beta2/Jenkinsfile).
>>
>> The same technique is being used in for many more branches in my
>> evaluation fork of that plugin repository.  Some examples include
>> https://github.com/MarkEWaite/git-plugin/blob/3.0.0-beta/Jenkinsfile ,
>> https://github.com/MarkEWaite/git-plugin/blob/master-PR350-extendGitSCMSource/Jenkinsfile
>>  ,
>> https://github.com/MarkEWaite/git-plugin/blob/master-PR398-ioexception-from-submodule/Jenkinsfile
>>  and
>> https://github.com/MarkEWaite/git-plugin/blob/master-PR411-parallel-tests/Jenkinsfile
>>  .
>>
>> Thanks,
>> Mark Waite
>>
>> On Mon, Jun 13, 2016 at 4:40 AM Sverre Moe <[email protected]> wrote:
>>
> Pipelines with Jenkinsfile runs in a sandbox and thus you need to approve
>>> certain functions.
>>> Manage Jenkins -> In-process Script Approval
>>>
>>>
>>> mandag 13. juni 2016 12.32.14 UTC+2 skrev Jerry Steele følgende:
>>>>
>>>> Thanks for getting me started on this. If you don't mind helping me
>>>> troubleshoot, I'll carry on:
>>>>
>>>> I think the parameterized version is the one I need, as I would like
>>>> the build tool to run with the $gitBranch argument of the new branch that
>>>> has just been created. However, when I attempt to run this job, I get the
>>>> following error:
>>>>
>>>> First time build. Skipping changelog. [Pipeline] End of Pipeline 
>>>> org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: 
>>>> Scripts not permitted to use method groovy.lang.Binding hasVariable 
>>>> java.lang.String at 
>>>> org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:160)
>>>>  at 
>>>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:119)
>>>>  at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149) at 
>>>> org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146) at 
>>>> com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:15)
>>>>  at WorkflowScript.run(WorkflowScript:4) at ___cps.transform___(Native 
>>>> Method) at 
>>>> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:55)
>>>>  at 
>>>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
>>>>  at 
>>>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
>>>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>>  at 
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>  at java.lang.reflect.Method.invoke(Method.java:606) at 
>>>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>>>>  at 
>>>> com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at 
>>>> com.cloudbees.groovy.cps.Next.step(Next.java:58) at 
>>>> com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at 
>>>> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
>>>>  at 
>>>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:276)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:78)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:185)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:183)
>>>>  at 
>>>> org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
>>>>  at java.util.concurrent.FutureTask.run(FutureTask.java:262) at 
>>>> hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
>>>>  at 
>>>> jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
>>>>  at 
>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at 
>>>> java.util.concurrent.FutureTask.run(FutureTask.java:262) at 
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>  at 
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>  at java.lang.Thread.run(Thread.java:745) Finished: FAILURE
>>>>
>>>> This seems to suggest that the if statement is not possible for
>>>> security reasons. Is the branch name exposed as an environment variable
>>>> that I can grab in the Jenkinsfile? Or alternatively, can I change the
>>>> security settings to allow the script to run?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> On Friday, 10 June 2016 20:31:18 UTC+1, Craig Rodrigues wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> You can try something like this to get started:
>>>>>
>>>>>
>>>>> def gitUrl = "https://github.com/twisted/twisted.git";
>>>>> def gitBranch = "trunk"
>>>>>
>>>>> node {
>>>>>     stage "Check out from Git"
>>>>>     git branch: "$gitBranch", url: "$gitUrl"
>>>>>
>>>>>     stage "Build code"
>>>>>     sh "sudo -Hs build_tool arg1 $gitUrl subproject_a $gitBranch"
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> I would recommend going further.  Make your Pipeline job
>>>>> parameterized.  Add a parameter GIT_BRANCH,
>>>>> and set the default value of that to the branch you want to build in
>>>>> that specific job.
>>>>>
>>>>>
>>>>> def gitUrl = "https://github.com/twisted/twisted.git";
>>>>> def gitBranch
>>>>>
>>>>> if (getBinding().hasVariable("GIT_BRANCH")) {
>>>>>     gitBranch = GIT_BRANCH
>>>>> }
>>>>>
>>>>> node {
>>>>>     stage "Check out from Git"
>>>>>     git branch: "$gitBranch", url: "$gitUrl"
>>>>>
>>>>>     stage "Build code"
>>>>>     sh "sudo -Hs build_tool arg1 $gitUrl subproject_a $gitBranch"
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> You can add more build parameters as you need.
>>>>>
>>>>> --
>>>>> Craig
>>>>>
>>>>> On Fri, Jun 10, 2016 at 8:40 AM, Jerry Steele <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm looking into getting Jenkins to build feature branches for our
>>>>>> github projects, but I'm not entirely sure where to start. Pipeline looks
>>>>>> like it might fit the bill, but I'm having trouble getting my head round
>>>>>> the Jenkinsfile. I've found the online docs and the "Groovy" generator 
>>>>>> but
>>>>>> am not really sure how to tie it all together. If anyone has a bit oftime
>>>>>> to help me, that would be great :)
>>>>>>
>>>>>> We currently use our own build tool to test code as deployed to
>>>>>> github, then build the artifacts into a debian package which is uploaded 
>>>>>> to
>>>>>> Amazon S3 and deployed by hand later.
>>>>>>
>>>>>> We currently have separate jobs for each of the major branches of our
>>>>>> project:
>>>>>>
>>>>>> subproject_a-qa
>>>>>> subproject_a-staging
>>>>>> subproject_a-production
>>>>>>
>>>>>> subproject_b-qa
>>>>>> subproject_b-staging
>>>>>> subproject_b-production
>>>>>>
>>>>>> subproject_c-qa
>>>>>> subproject_c-staging
>>>>>> subproject_c-production
>>>>>>
>>>>>> The jobs are very simple - they poll github, looking at a specific
>>>>>> branch, then if that has changed, they will execute a shell script which
>>>>>> looks like this (generic):
>>>>>>
>>>>>> sudo -Hs build_tool arg1 $GIT_URL <subproject_a> <environment(qa/
>>>>>> staging/prod)>
>>>>>>
>>>>>> So, what I'd need is something that builds the following jobs when a
>>>>>> feature branch is pushed to look something like:
>>>>>>
>>>>>> sudo -Hs build_tool arg1 $GIT_URL <subproject_a>
>>>>>> <feature_branch_name>
>>>>>> sudo -Hs build_tool arg1 $GIT_URL <subproject_b>
>>>>>> <feature_branch_name>
>>>>>> sudo -Hs build_tool arg1 $GIT_URL <subproject_c>
>>>>>> <feature_branch_name>
>>>>>>
>>>>>> Or else, know how to build those.
>>>>>>
>>>>>> Is this possible with Pipeline? Or am I looking at the wrong tool
>>>>>> here? I've started a multibranch test project, but am basically stuck at
>>>>>> the Jenkinsfile stage, and most tutorials appear to refer to using mvn,
>>>>>> which I'm not familiar with. the build tool is written in Python and is
>>>>>> testing building for Ruby on Rails :)
>>>>>>
>>>>>> Any help very much appreciated. Any more info needed, please let me
>>>>>> know...
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jerry
>>>>>>
>>>>>> --
>>> 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/649bffd5-727d-49a5-991b-67ee068dcb4a%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/649bffd5-727d-49a5-991b-67ee068dcb4a%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/e9f89c01-4539-43d5-be3a-1fc2d6923707%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/e9f89c01-4539-43d5-be3a-1fc2d6923707%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/CAO49JtFwLz0ji%2BEwzuTPE0K%2BiaydzMNB3X%3DrpAMhp3cpFZof-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to