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