Pipeline: wildcard for branch name

[Sharan Basappa]

Hi,

I am trying to create pipeline script such that it only a certain branches following a naming style are built.

However, pipeline bails out when I use the wildcard.

The code snippet is below:

stage 'build'

node {

git url: 'git@hd1:testing', branch: test*

sh "pwd"

sh "cat simple.csh"

sh "echo $PATH"

sh "csh simple.csh"

echo("end of pipeline")

}

I see the following output from the above script:

Started by user User

[Pipeline] stage (build)

Using the ‘stage’ step without a block argument is deprecated

Entering stage build

Proceeding

[Pipeline] node

Running on master in /var/lib/jenkins/workspace/test_build_3

[Pipeline] {

[Pipeline] }

[Pipeline] // node

[Pipeline] End of Pipeline

groovy.lang.MissingPropertyException: No such property: test for class: WorkflowScript

        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)

        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)

        at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.getProperty(DefaultInvoker.java:33)

        at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)

        at WorkflowScript.run(WorkflowScript:6)

        at ___cps.transform___(Native Method)

        at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)

        at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)

        at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)

        at sun.reflect.GeneratedMethodAccessor725.invoke(Unknown Source)

        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.CpsThread.runNextChunk(CpsThread.java:163)

        at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)

        at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)

        at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)

        at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)

        at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)

        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:744)

Finished: FAILURE

However, when I modify the script as follows:

stage 'build'

node {

git url: 'git@hd1:testing', branch: test*

sh "pwd"

sh "cat simple.csh"

sh "echo $PATH"

sh "csh simple.csh"

echo("end of pipeline")

}

the code executes properly and I get the following output:

Started by user User

[Pipeline] stage (build)

Using the ‘stage’ step without a block argument is deprecated

Entering stage build

Proceeding

[Pipeline] node

Running on master in /var/lib/jenkins/workspace/test_build_3

[Pipeline] {

[Pipeline] git

 > git rev-parse --is-inside-work-tree # timeout=10

Fetching changes from the remote Git repository

 > git config remote.origin.url git@hd1:testing # timeout=10

Fetching upstream changes from git@hd1:testing

 > git --version # timeout=10

 > git fetch --tags --progress git@hd1:testing +refs/heads/*:refs/remotes/origin/*

 > git rev-parse refs/remotes/origin/test^{commit} # timeout=10

 > git rev-parse refs/remotes/origin/origin/test^{commit} # timeout=10

Checking out Revision 264dc398372cba41c026568bd764d2656ebfc511 (refs/remotes/origin/test)

 > git config core.sparsecheckout # timeout=10

 > git checkout -f 264dc398372cba41c026568bd764d2656ebfc511

 > git branch -a -v --no-abbrev # timeout=10

 > git branch -D test # timeout=10

 > git checkout -b test 264dc398372cba41c026568bd764d2656ebfc511

 > git rev-list 264dc398372cba41c026568bd764d2656ebfc511 # timeout=10

[Pipeline] sh

[test_build_3] Running shell script

+ pwd

/var/lib/jenkins/workspace/test_build_3

[Pipeline] sh

[test_build_3] Running shell script

+ cat simple.csh

#!/bin/csh

echo "welcome to jenkins from test branch"

[Pipeline] sh

[test_build_3] Running shell script

+ echo /sbin:/usr/sbin:/bin:/usr/bin

/sbin:/usr/sbin:/bin:/usr/bin

[Pipeline] sh

[test_build_3] Running shell script

+ csh simple.csh

welcome to jenkins from test branch

[Pipeline] echo

end of pipeline

[Pipeline] }

[Pipeline] // node

[Pipeline] End of Pipeline

Finished: SUCCESS

I need some help to figure this out why it fails when I try to use wildcard.

Note that, I also tried different ways of specifying the test branch - "test*"

[Victor Martinez]

Test property doesn't exist so, according to the doc:

- https://jenkins.io/doc/pipeline/steps/git/#git-git

-- branch is a string therefore you need to quote it otherwise it seems it's recognised as a property 

You can also try with the generic scm step, explained also in the same page

Cheers

[Sharan Basappa]

Victor,

I tried all options as follows:

git url: 'git@hd1:testing', branch: "test*"

git url: 'git@hd1:testing', branch: test*

git url: 'git@hd1:testing', branch: 'test*'

In all the 3 cases, Jenkins exits with error. I looked into the log again and this is what I see:

Caused by: hudson.plugins.git.GitException: Command "git checkout -b test* 264dc398372cba41c026568bd764d2656ebfc511" returned status code 128:

stdout:

stderr: fatal: git checkout: we do not like 'test*' as a branch name.

Somehow, Git is trying to checkout a branch with a wildcard which is anyway not my intent.

All I wan't is to checkout from a branch which follows naming convention such as test* (e.g. testa, testb etc.)

Can someone help?

[Indra Gunawan (ingunawa)]

You can’t use the simple git pipeline command if you want to be fancy

 

You should use the form where you can specify more options like configuring Git SCM:

 

checkout scm: [$class: 'GitSCM', branches: [[name: '*/test*']], userRemoteConfigs: [[url: 'git@hd1:testing']]]

--
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/41830d01-040f-477c-a0b3-4f8db4c3ae0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Karr]

Perhaps I'm missing something, but I believe you might be missing the point of the "git" pipeline step.  It's intended to take a git url, branch name, and credentials and perform a clone into the workspace. It doesn't make sense to try to supply a wildcard value there.

[Sharan Basappa]

Hi David,

I am new to continuous integration and Jenkins, so I need inputs to go in the right direction.

My requirement is that users push branches with name test_id1/test_id2 etc.

I would like to build only when users have created branches with the above name.

So, after seeing the responses, it looks like I have to:

1)  first checkout the repository

2)  list out the branches,

3)  if branch name matches test* then I checkout the corresponding branch and do rest of the build

I need inputs here ...

[Mark Waite]

You may find it easier to start with a freestyle job so that you can work through the steps with a little more help from the Jenkins web interface.  A freestyle job will let you define the branch with a wild card and will let you see your build results, see the summary of test results, etc.  That will give you a single job which switches from one branch to another.  I find results from that type of job more difficult to read because it mixes different branches into the history of the same job.

Once you have a freestyle job working, then you can move to a pipeline job, and use the "Pipeline Syntax" link on the web interface to select "checkout".  In that page, you'll make the same selections as you made in the freestyle job definition, including placing the branch name you want as a wild card.  That will give you a single pipeline which will switch between the branches as branches are created or as commits are added to those branches.  I find results from that type of job more difficult to read because it mixes different branches into the history of the same job.

Once you have a working pipeline job, then you can move to a multi-branch pipeline job, using the pipeline definition from the pipeline job.  The multi-branch pipeline job will automatically define a job for each branch that matches your branch name wildcard, and can run that job when commits are detected on that branch.  Results will be presented with a job per branch, so users will see the results on their branch, without intermixing changes from other branches in the job history.

If you're a docker user, you can see examples of each of those types of jobs in the lts-with-plugins branch of my Jenkins docker definition (https://github.com/MarkEWaite/docker/tree/lts-with-plugins) .

Mark Waite

--

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/03968e1f-0b02-486d-85a8-a830c0b1509c%40googlegroups.com.

[Indra Gunawan (ingunawa)]

HI Sharan,

 

I sent this already:

 

 

You can’t use the simple git pipeline command if you want to be fancy

 

You should use the form where you can specify more options like configuring Git SCM:

 

checkout scm: [$class: 'GitSCM', branches: [[name: '*/test*']], userRemoteConfigs: [[url: 'git@hd1:testing']]]

 

 

From: <jenkins...@googlegroups.com> on behalf of Sharan Basappa <sharan....@gmail.com>
Reply-To: "jenkins...@googlegroups.com" <jenkins...@googlegroups.com>
Date: Thursday, January 26, 2017 at 4:03 AM
To: Jenkins Users <jenkins...@googlegroups.com>
Subject: Re: Pipeline: wildcard for branch name

 

Hi David,

--

[Sharan Basappa]

Hi Mark, Indra,

If I use wildcard as a branch specifier then what would happen if there are multiple matches?

I would like to know this because my requirement is take each branch and then build each of them separately.

[Mark Waite]

The freestyle job is a single job which would build each branch that matches as part of that single job.

The multi-branch pipeline will automatically create a job per branch which matches the wildcard and has a Jenkinsfile.  That's where you ultimately want to go.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/beb3ca75-1597-416c-99da-858d1880dd6d%40googlegroups.com.

[Sharan Basappa]

Mark,

I cant use freestyle job for the simple reason that, what we are doing would become a sort of best practice for many projects.

Gui based approach is, in my view,  not a good way to share the best practice.

I will check out multi branch pipeline. Thanks a lot