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.
