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 <sverre....@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-users+unsubscr...@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/CAO49JtGONpMZ%2B-AdzkBGnB-jBQ5VxTrGy%3DA%2B7_rcNHfj_Lsc0g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
