Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

On Tuesday, January 12, 2016 at 10:51:11 AM UTC+1, Stephen Connolly wrote:
>
>
>
> On 12 January 2016 at 06:14, Thomas Goeppel <thomas@gmail.com 
> > wrote:
>
>> Stephen,
>>
>> thanks for the suggestions. I'm sure that with the two methods you 
>> described it's possible to divide roles into those who can control a docker 
>> host, and those who can't, and the second method is even safe against 
>> privilege escalation. The organization I work for is a Cloudbees customer, 
>> but unfortunately both methods you suggested don't support use cases where 
>> both groups in your "lock down" scenario must be allowed to configure 
>> Workflow scripts with `docker.image().inside{}` (and that's what I have in 
>> mind).
>>
>
> If you are using the Script Security plugin that should help vet what 
> scripts can be executed... and by having the two teams in different Jenkins 
> masters you can have different profiles of what they can run... but yeah I 
> agree it would be better to be able to provide a "permission restricted" 
> docker proxy to the build (not just workflow by the way) so that you can 
> restrict what the build can do as this is a problem for any build (just 
> think that somebody can add a unit test that uses System.exec to run docker
>  
>

Exactly that's my concern - I don't want to rely on Jenkins security for 
this kind of system level stuff. On the OS level, Jenkins operates under a 
single user account for all jobs. It would be easier if Jenkins could run 
jobs with setuid(), e.g. depending on the user roles that 'own' a job. 
Currently that only possible on the build slave level.

-- 
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/8ec6a1fe-0da6-4f11-b446-c85f644780e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

Stephen,

thanks for the suggestions. I'm sure that with the two methods you 
described it's possible to divide roles into those who can control a docker 
host, and those who can't, and the second method is even safe against 
privilege escalation. The organization I work for is a Cloudbees customer, 
but unfortunately both methods you suggested don't support use cases where 
both groups in your "lock down" scenario must be allowed to configure 
Workflow scripts with `docker.image().inside{}` (and that's what I have in 
mind).

FYI: I did some tests with the "setuid docker proxy" method I proposed. 
Writing a docker shim that filters commands and parameters to prevent 
privilege escalation seems to be feasible (i.e. one that only passes on 
commands, flags, and arguments in compliance with the intended use case in 
Jenkins Workflow). 

/Thomas

On Monday, January 11, 2016 at 11:34:34 PM UTC+1, Stephen Connolly wrote:
>
> You can use a feature such as 
> http://documentation.cloudbees.com/docs/cje-user-guide/foldersplus-sect-controlledslaves.html
>  
> so that only jobs in a specific folder can use the build slave... then you 
> can use an authorization strategy (
> http://documentation.cloudbees.com/docs/cje-user-guide/rbac.html pairs 
> well but there are others) so that only trusted users can configure jobs in 
> that folder... yes there are still ways to hack around if you don't use 
> script security or let untrusted users run jobs on the Jenkins master... 
> but a locked down Jenkins is still possible...
>
> If you want something even more secure you can have multiple Jenkins 
> instances connected together and trigger the jobs on the locked down ones 
> from slightly lesser locked down ones: 
> http://documentation.cloudbees.com/docs/cjoc-user-guide/cluster-triggers.html
>
> All the above is possible (i.e. I wrote a good chunk of that 
> functionality) so even if you didn't want to purchase from CloudBees it is 
> possible to implement the same in plugins (though the CJOC stuff would be a 
> bigger chunk of work)
>
> On 11 January 2016 at 20:01, Thomas Goeppel <thomas@gmail.com 
> > wrote:
>
>> Stephen,
>>
>> thanks for your reply. You're right, nobody would run Jenkins as root in 
>> a production environment, but  through the Cloudbees Docker Workflow plugin 
>> Jenkins is in control of the docker client, and hence it's root on some 
>> machine (e.g. a build slave). 
>>
>> I don't really understand what you mean with "running a build slave as 
>> the trusted account". Maybe I'm missing something here, but from a security 
>> point of view, as soon as untrusted users control a docker host on a build 
>> slave (e.g. through Jenkins job definitions) that build slave is all but 
>> trusted, and an untrusted machine has no place in a corporate network. If 
>> one builds a firewall around an untrusted build slave as mitigation, I 
>> would expect practical problems accessing SCM or artifact repositories 
>> inside the corporate network from that slave.
>>
>> Calling the docker client through Jenkins can be considered safe if 
>> Jenkins runs in a locked down environment (where only trusted users can 
>> define jobs), or if the docker host (build slave) is short lived (e.g. an 
>> ephemeral VM like Boot2Docker). Unfortunately, non of these options would 
>> work for me.
>>
>> /Thomas
>>
>>
>> On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote:
>>>
>>> FYI you do not run *Jenkins* as root... rather you run a build slave as 
>>> the trusted account and then you lock down access to that build slave... 
>>> e.g. if that build slave deploys into production you can use it as a kind 
>>> of bastion host whereby it is off-line until you want to deploy into 
>>> production.
>>>
>>> On 10 January 2016 at 11:17, Thomas Goeppel <thomas@gmail.com> 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>>>>>
>>>>> > One option would be to write a shim for the docker command, that 
>>>>> only 
>>>>> > allows a subset of commands, and sanitizes the options and 
>>>>> parameters. 
>>>>>
>>>>> Even if you do that, the jenkins user, as part of the docker group, 
>>>>> will 
>>>>> still have direct access to the unix socket that the Docker daemon 
>>>>> uses. 
>>>>>
>>>>>
>>>> As is quite often the case with a CI server, you most likely need to 
>>>>&g

Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

Stephen,

thanks for your reply. You're right, nobody would run Jenkins as root in a 
production environment, but  through the Cloudbees Docker Workflow plugin 
Jenkins is in control of the docker client, and hence it's root on some 
machine (e.g. a build slave). 

I don't really understand what you mean with "running a build slave as the 
trusted account". Maybe I'm missing something here, but from a security 
point of view, as soon as untrusted users control a docker host on a build 
slave (e.g. through Jenkins job definitions) that build slave is all but 
trusted, and an untrusted machine has no place in a corporate network. If 
one builds a firewall around an untrusted build slave as mitigation, I 
would expect practical problems accessing SCM or artifact repositories 
inside the corporate network from that slave.

Calling the docker client through Jenkins can be considered safe if Jenkins 
runs in a locked down environment (where only trusted users can define 
jobs), or if the docker host (build slave) is short lived (e.g. an 
ephemeral VM like Boot2Docker). Unfortunately, non of these options would 
work for me.

/Thomas


On Monday, January 11, 2016 at 3:08:41 PM UTC+1, Stephen Connolly wrote:
>
> FYI you do not run *Jenkins* as root... rather you run a build slave as 
> the trusted account and then you lock down access to that build slave... 
> e.g. if that build slave deploys into production you can use it as a kind 
> of bastion host whereby it is off-line until you want to deploy into 
> production.
>
> On 10 January 2016 at 11:17, Thomas Goeppel <thomas@gmail.com 
> > wrote:
>
>>
>>
>> On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>>>
>>> > One option would be to write a shim for the docker command, that only 
>>> > allows a subset of commands, and sanitizes the options and parameters. 
>>>
>>> Even if you do that, the jenkins user, as part of the docker group, will 
>>> still have direct access to the unix socket that the Docker daemon uses. 
>>>
>>>
>> As is quite often the case with a CI server, you most likely need to 
>>> either trust the users who can configure jobs (or edit Workflow scripts 
>>> (if in source control)), or lock down the Jenkins configuration to allow 
>>> only specific users. 
>>>
>>>
>>
>>> The Docker security guide also says "only trusted users should be 
>>> allowed to control your Docker daemon": 
>>> https://docs.docker.com/engine/articles/security/ 
>>>
>>> I feel that you're mixing up two areas of trust here, Jenkins (and CI 
>> users), and Docker (and system administrators). In an organization of any 
>> size or complexity, the roles allowed to control Jenkins won't be held by 
>> the same people that have the roles with root access. Even if it were so, 
>> just how much would one have to lock down a Jenkins production environment 
>> to mitigate the risks associated with running Jenkins as root, i.e. user 
>> "jenkins" in the group "docker"? 
>>
>> We could give up on provisioning containerized toolchains through Jenkins 
>> in a Non-Root-Jenkins production environment, but there is a lot of value 
>> in running and controlling Docker containers through Jenkins. Fortunately, 
>> full control of Docker isn't required for this use case: Jesse Glick 
>> demonstrated that nicely with the implementation of docker.image().inside 
>> {} that passes reasonably safe parameters through the Docker CLI (e.g. -u 
>> non-root).
>>
>> Obviously, delegation of watching over safe use of the Docker CLI to 
>> Jenkins isn't possible in any environment where we can't run Jenkins as 
>> "root" ("docker"), and hence we need a trusted proxy. Technically that 
>> proxy might run with "setuid docker" (and have access to the Unix socket), 
>> or use a web service, but I think that the docker counterpart to a 
>> "restricted 
>> shell <https://en.wikipedia.org/wiki/Restricted_shell>" would be best.
>>
>> -- 
>> 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/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com?utm_medium=email_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/e20cbe1a-6da3-4e39-86cc-7055b5109995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

On Sunday, January 10, 2016 at 1:05:07 AM UTC+1, Christopher Orr wrote:
>
> > One option would be to write a shim for the docker command, that only 
> > allows a subset of commands, and sanitizes the options and parameters. 
>
> Even if you do that, the jenkins user, as part of the docker group, will 
> still have direct access to the unix socket that the Docker daemon uses. 
>
>
As is quite often the case with a CI server, you most likely need to 
> either trust the users who can configure jobs (or edit Workflow scripts 
> (if in source control)), or lock down the Jenkins configuration to allow 
> only specific users. 
>
>

> The Docker security guide also says "only trusted users should be 
> allowed to control your Docker daemon": 
> https://docs.docker.com/engine/articles/security/ 
>
> I feel that you're mixing up two areas of trust here, Jenkins (and CI 
users), and Docker (and system administrators). In an organization of any 
size or complexity, the roles allowed to control Jenkins won't be held by 
the same people that have the roles with root access. Even if it were so, 
just how much would one have to lock down a Jenkins production environment 
to mitigate the risks associated with running Jenkins as root, i.e. user 
"jenkins" in the group "docker"? 

We could give up on provisioning containerized toolchains through Jenkins 
in a Non-Root-Jenkins production environment, but there is a lot of value 
in running and controlling Docker containers through Jenkins. Fortunately, 
full control of Docker isn't required for this use case: Jesse Glick 
demonstrated that nicely with the implementation of docker.image().inside 
{} that passes reasonably safe parameters through the Docker CLI (e.g. -u 
non-root).

Obviously, delegation of watching over safe use of the Docker CLI to 
Jenkins isn't possible in any environment where we can't run Jenkins as 
"root" ("docker"), and hence we need a trusted proxy. Technically that 
proxy might run with "setuid docker" (and have access to the Unix socket), 
or use a web service, but I think that the docker counterpart to a "restricted 
shell " would be best.

-- 
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/aa632bac-58cb-4e3f-9238-ab1ad4424fe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Security best practice for Cloudbees Docker Workflow?

[Thomas Goeppel]

Hello community,

I've been experimenting with the Cloudbees Docker Workflow plugin, and I 
really like the ease of use of this DSL. Now I'd like to get security right.

Problem: the plugin assumes that the docker binary is in the path 
. 
In my understanding this has the implication that the user that issues 
docker commands (e.g. jenkins) has to be in the docker group!

The *docker* variable provided by the docker workflow plugin limits the 
security impact by explicitly setting a non-priviledged  user with the "-u" 
option. However, at least in docker 1.9.1 I can pass a second "-u" option 
which overwrites the original settings:

docker.image('ubuntu').inside ('-v /etc:/etc-host -u 0') {
> sh '''
> whoami
> # -> root
> awk '{gsub(/[A-Z]/,"!"); print}' /etc-host/shadow
> # -> slightly masked password hashes 
> '''
> }
>
> I could also have passed in the "--privileged" flag. 

For a moment I asked myself it it would be worthwhile filing an ER, as to 
have the plugin sanitize the "docker run" parameters. But the fundamental 
problem is that a Jenkins job has the right to run the docker commands. 
Running the following script would be even worse:

node {
> sh 'docker run  -v /etc:/etc-host ubuntu cat /etc-host/shadow' 
> }  
>

One option would be to write a shim for the docker command, that only 
allows a subset of commands, and sanitizes the options and parameters.

My question are these: 

   - am I missing something?
   - how should I configure the Jenkins CI environment (server and nodes) 
   to use the docker command safely?

Thanks in advance,

Thomas

-- 
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/62e8e1dd-382e-4fb3-baff-e816099b00a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Thomas Goeppel]

Hi John,

your approach sounds interesting. Could you please share some Workflow code 
that shows how you compute the Workspace location, use ws(), and pass 
workspace locations to subsequent jobs? 

When accessing workspaces in Workflow you're also facing the problem of 
concurrent runs. How do you deal with that?

Thanks in advance!

Greetings,
Thomas
 

On Wednesday, December 30, 2015 at 3:11:46 AM UTC+1, Martin d'Anjou wrote:
>
> On Wednesday, December 23, 2015 at 9:45:57 PM UTC-5, John D. Ament wrote:
>>
>> Hi,
>>
>> I was wondering if anyone had any best practices or tips to share on have 
>> a common workspace for a pipeline job.
>>
>
> I use Workflow job definitions, and I compute the location of the 
> workspace in each job of the build chain before the actual build actions 
> take place, using the ws() built step. Subsequent jobs in the build chain 
> use the same workspace (the location can be computed). Subsequent jobs need 
> not to be in the same workflow definition, nor in a formal pipeline (I do 
> not use triggers nor pipeline plugins). I have enough input parameters for 
> the subsequent jobs in the chain to locate the workspace of the previous 
> job. I do not move nor archive data (I have thousands of files and 
> gigabytes of data over NFS so I don't want to spend time moving it or 
> archiving/extracting it).
>

-- 
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/8724e85d-36e2-4e1d-a920-f9047587aada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Thomas Goeppel]

Oh sorry, wrong addressee  

%s/John/Martin/ :-)


On Wednesday, December 30, 2015 at 11:24:26 AM UTC+1, Thomas Goeppel wrote:
>
> Hi John,
>

-- 
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/53be2f41-9a45-4af5-a952-c49f53ef94b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any plugin to parse XML?

[Thomas Goeppel]

> Have not tried it, but it is probably doable. Use readFile to download the 
> file contents from the slave. Then use standard Groovy APIs to parse; you 
> might need to wrap the details in a function marked @NonCps.
>

Thanks Jesse, this works.

-- 
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/00a8c265-9668-4313-8aa2-82f653ee8b1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Script-SCM - example scripts?

[Thomas Goeppel]

Hi,

it would be very nice if anybody could share an example Groovy script with 
matching Ant configuration for the Script-SCM plugin.

Thanks!
 

-- 
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/9b26ccf7-7a49-44bc-88ad-c53a9b9b929c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow-plugin] Use external script for running the flow

[Thomas Goeppel]

Hi Timur,

did I get this right, besides the Groovy CPS DSL from SCM you don't use a 
general a General SCM step? 

In my understanding, loading the flow definition from an SCM is just a 
special case of using multiple SCMs 
https://github.com/jenkinsci/workflow-plugin/tree/master/scm-step (at 
least that's what I would expect it to be). Did you try using an additional 
General SCM step with the Cleanup workdir option active?

/Thomas

On Sunday, February 1, 2015 at 1:45:16 AM UTC+1, Timur Batyrshin wrote:

 Hi Thomas,

 Yes, I've noticed the new version soon and I'm using it for about a week. 
 Sorry that I've not updated the maillist with my finding.
 I'm using git for the groovy script and it works exactly the same as if I 
 used standalone git checkout.
 I've just could not figure out how to correctly specify additional actions 
 like Cleanup workdir after checkout.
 If you know how to do that please let me know.

 Thanks,
 Timur 

 воскресенье, 1 февраля 2015 г., 0:59:20 UTC+3 пользователь Thomas Goeppel 
 написал:

 Hi Timur,

 good news, loading the CPS script from SCM (i.e. Git or SVN) is one of 
 the new features in workflow plugin 1.2. Just add your script to your SCM, 
 select Groovy CPS DSL from SCM instead of Groovy CPS DSL, enter your 
 repository, and the name of your Groovy CPS script. 

 I did a quick test with Subversion: it works, but I had to experiment a 
 while with the settings to make my script work. It looks like Jenkins tries 
 to be smart about the location of trunk/ in the repository path, which is 
 odd, since the repository structure should be none of its business ;-)

 I also couldn't figure out what Local module directory, and Add 
 module are about. After setting the Locale module directory, I had to 
 add a dir { } instruction. Without that the script started in the wrong 
 directory. I guess, that these are Subversion related issues.

 /Thomas

 On Monday, January 19, 2015 at 11:05:19 AM UTC+1, Timur Batyrshin wrote:

 Hi,

 I'd like to store the script for running the flow in Git but it looks 
 like I can't do the SCM checkout before running the flow.
 I could write some additional lines in the flow script (one for checkout 
 and one load command) but the checkout commands
 are too large in the current state (like:
 checkout changelog: true, poll: true, scm: [$class: 'GitSCM', branches: 
 [[name: 'remotes/origin/master']], userRemoteConfigs: [[credentialsId: 
 'XXX-XX-X-XXX', url: '
 https://github.com/X/XX.git']]]
 ).

 Is there a way to do the initial checkout using plain Jenkins checkout 
 feature or should I use this approach? Probably some other ways of doing 
 that?


 Thanks,
 Timur



-- 
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/0aba707e-f991-49ff-9652-40a28fe9b020%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow-plugin] Use external script for running the flow

[Thomas Goeppel]

Hi Timur,

good news, loading the CPS script from SCM (i.e. Git or SVN) is one of the 
new features in workflow plugin 1.2. Just add your script to your SCM, 
select Groovy CPS DSL from SCM instead of Groovy CPS DSL, enter your 
repository, and the name of your Groovy CPS script. 

I did a quick test with Subversion: it works, but I had to experiment a 
while with the settings to make my script work. It looks like Jenkins tries 
to be smart about the location of trunk/ in the repository path, which is 
odd, since the repository structure should be none of its business ;-)

I also couldn't figure out what Local module directory, and Add module 
are about. After setting the Locale module directory, I had to add a dir 
{ } instruction. Without that the script started in the wrong directory. I 
guess, that these are Subversion related issues.

/Thomas

On Monday, January 19, 2015 at 11:05:19 AM UTC+1, Timur Batyrshin wrote:

 Hi,

 I'd like to store the script for running the flow in Git but it looks like 
 I can't do the SCM checkout before running the flow.
 I could write some additional lines in the flow script (one for checkout 
 and one load command) but the checkout commands
 are too large in the current state (like:
 checkout changelog: true, poll: true, scm: [$class: 'GitSCM', branches: 
 [[name: 'remotes/origin/master']], userRemoteConfigs: [[credentialsId: 
 'XXX-XX-X-XXX', url: '
 https://github.com/X/XX.git']]]
 ).

 Is there a way to do the initial checkout using plain Jenkins checkout 
 feature or should I use this approach? Probably some other ways of doing 
 that?


 Thanks,
 Timur


-- 
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/9d0c5eb0-ad59-41d1-907a-caa7c95fdfae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Groovy collection.find() returning boolean in Workflow scripts?!

[Thomas Goeppel]

Kenneth,

CPS doesn't always behave like a Groovy programmer would expect. Obviously, 
there is a price to pay for the double nature of CPS as a job description, 
and scripting language (*README.md refers to this as continuation passing 
style* transformation of the script).

However, List.find seems to return the first result of the closure (in your 
case 'false'), and this is plain wrong. Yes, I would file a bug. Either 
this should work, or 'find' shouldn't be part of CPS.

Best,
Thomas

On Tuesday, January 6, 2015 2:10:15 AM UTC+1, Kenneth Baltrinic wrote:

 I am trying to do a very simple file parse operation within a Jenkins 
 workflow script and getting some very bizarre results.  This is with the 
 workflow 1.1 set of plugins and Jenkins 1.596.  

 To demonstrate the issue I created a new workflow job with the following 
 script:






 *def str=1:one|2:two|3:threedef i = 2def opts = str.split(/\|/)def opt 
 = opts.find { o - o.contains(${i}:) }echo len: ${opts.length}echo 
 opt: ${opt}*

 The output of which is 







 *Started by user anonymous http://192.168.33.36:8080/user/nullRunning: 
 Print Messagelen: 3Running: Print Messageopt: falseRunning: End of 
 WorkflowFinished: SUCCESS*


 However, running effectively the same script in the Jenkins script console 
 (or any other groovy environment I have tried) produces the expected result:






 *def str=1:one|2:two|3:threedef i = 2def opts = str.split(/\|/)def opt 
 = opts.find { o - o.contains(${i}:) }println len: 
 ${opts.length}println opt: ${opt}*

 returns:


 *len: 3**opt: 2:two*


 Am I missing something really obvious or should I open a bug report for 
 this?


-- 
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/081494b9-fa8c-4eef-a1bc-712582400138%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.