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 <ticktockho...@gmail.com> 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 <sverr...@gmail.com> 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 <tickto...@gmail.com> >>>>> 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 jenkinsci-use...@googlegroups.com. >> >> >>> 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. 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.
