Build pipeline plugin

[Prabu Uthirapathi]

 When I tried to download the build pipeline plugin, the download is 
failing before finishing..the 2.4 mb . Please help 

-- 
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/2c1f6149-59fe-4538-ba22-a37d64ef4a47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins 2.0 and the game of life

[Sarah Baker]

Greetings,
I'm working thru the book 'Jenkins, The Definitive Guide'

Jenkins 2.0, Java 8 update 92, Maven 3.3.9 on Windows.
Jenkins is installed, game of life built fine.
This problem relates to the section  "More Reporting - Displaying Javadocs".
The maven target javadoc:javadoc fails with issues (see below).  
I am not familiar enough with Maven to understand the source of the 
problem. 
I suspect Jenkins, or some configuration inside Jenkins.
I had at first assumed it was something wrong with my maven install, but
I removed it completely, allowing jenkins to install it (option in the 
Global Tool Configuration for Maven), the same problem occurred.  
When I run the mvn command outside of jenkins at the command line in the 
same directory, it builds without any errors.
I cannot find a similar problem posted anywhere thusfar.  
Thank you for any clues.

C:\Users\Sarah\.jenkins\jobs\gameoflife-default\workspace>"C:\Program 
Files\Apache\Maven\bin\\mvn.cmd" javadoc:javadoc -o 
[INFO] Scanning for projects...
[INFO] 

[INFO] Reactor Build Order:
[INFO] 
[INFO] gameoflife
[INFO] gameoflife-build
[INFO] gameoflife-core
[INFO] gameoflife-web
[WARNING] The POM for org.apache.maven.plugins:maven-release-plugin:jar:2.5 
is missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-release-plugin:2.5: Plugin 
org.apache.maven.plugins:maven-release-plugin:2.5 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-release-plugin:jar:2.5 has not been 
downloaded from it before.
[WARNING] The POM for 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2 is missing, no 
dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-deploy-plugin:2.8.2: Plugin 
org.apache.maven.plugins:maven-deploy-plugin:2.8.2 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.8.2 has not been 
downloaded from it before.
[WARNING] The POM for com.jelastic:jelastic-maven-plugin:jar:1.6 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
com.jelastic:jelastic-maven-plugin:1.6: Plugin 
com.jelastic:jelastic-maven-plugin:1.6 or one of its dependencies could not 
be resolved: Cannot access central (https://repo.maven.apache.org/maven2) 
in offline mode and the artifact com.jelastic:jelastic-maven-plugin:jar:1.6 
has not been downloaded from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-site-plugin:jar:3.3 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-site-plugin:3.3: Plugin 
org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-site-plugin:jar:3.3 has not been downloaded 
from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-install-plugin:jar:2.4 
is missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-install-plugin:2.4: Plugin 
org.apache.maven.plugins:maven-install-plugin:2.4 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-install-plugin:jar:2.4 has not been 
downloaded from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 
is missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin 
org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been 
downloaded from it before.
[WARNING] The POM for 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 is missing, 
no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 has not been 
downloaded from it before.
[WARNING] The POM for 
org.apache.maven.plugins:maven-dependency-plugin:jar:2.8 is missing, no 
de

Access control in pipeline input step

[Lionel Orellana]

Hi

How can I restrict who can actually approve a manual (i.e. input) step in a 
pipeline? If I have a "Deploy to PROD" step I only want people with a 
particular role to be able to approve. Am I going about it the wrong way?

Thanks

Lionel. 

-- 
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/e67e22f7-6c03-4821-b50b-2a21a3079ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipelines, iterating maps and more headaches

[Craig Rodrigues]

Norm,

Take a look at this my posting from a few months ago:

https://groups.google.com/d/msg/jenkinsci-users/P7VMQQuMdsY/bHfBDSn9GgAJ

That link has pointers to the Groovy Script class and Groovy shell.
I think understanding those two classes will help improve your understanding
of Pipeline scripts, especially with respect to global variables.
I am new to Groovy, and it took me a long time to understand
what is going on with Pipeline scripts, before I started digging into the
code to figure things out.

--
Craig

On Tue, Apr 26, 2016 at 4:18 PM, Norbert Lange  wrote:

>
> 4) Are variables from Closures global??? Is this a Groovy thing or a bug???
>
>

-- 
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/CAG%3DrPVeYYBSX9Fo_mypnXcpzpcvJ0PzveVghBL%3DQLyuG_4C%2B%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipelines, iterating maps and more headaches

[Brian Ray]

Unless you're talking about your method declaration *def mapToList()*. In 
that case, the def is just window dressing AFAIK. The return type is the 
same with or without *def*: ie, *Object*.

On Wednesday, April 27, 2016 at 3:34:24 PM UTC-7, Brian Ray wrote:
>
> Nice hackaround. I will try that in the uncooperative parts of my script.
>
> Ah yes, *def x* vs *x*. On the face of it the two declarations should be 
> identical--roughly typing *x* as an *Object*. But there are different 
> scoping implications 
> 
>  
> for each.
>
> On Wednesday, April 27, 2016 at 3:00:43 PM UTC-7, Norbert Lange wrote:
>>
>> Hi Brian,
>>
>> every single method in the "final foo" - including the String 
>> Constructor requires approval. I was hoping for a proper subset that would 
>> work within the sandbox.
>> What I ended with (several dozen "Builds" later ) is using a helper 
>> function squeezing the map into a list, seems the most sane aproach so far 
>> =(
>>
>> Btw, whats the difference of using "def x" vs "x"?
>>
>> node {
>> 
>> for (it2 in mapToList(depmap)) {
>> name = it2[0]
>> revision = it2[1]
>> }
>> }
>> @NonCPS
>> def mapToList(depmap) {
>> def dlist = []
>> for (entry in depmap) {
>> dlist.add([entry.key, entry.value])
>> }
>> dlist
>> }
>>
>>
>>
>>
>> Am Mittwoch, 27. April 2016 18:26:51 UTC+2 schrieb Brian Ray:
>>>
>>> FWIW I recently replaced several C-style loops with *for ( x in y )* 
>>> for iterating over both lists and maps in CPS code and for the most part 
>>> conversion went fine. There were a couple of CPS sections where I could not 
>>> use that construct and had to fall back on the C-loops and further do a 
>>> torturous cast to avoid a serialization error getting keys and values from 
>>> the map. I want to say *Set>* caused the exception 
>>> because *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are 
>>> serializable, while *Set *is not, per the JDK.
>>>
>>> for ( int i = 0; i < myMap.size(); i++ ) {
>>>   
>>>   // hacktacular String() cloning to avoid NotSerializableException; 
>>> also 
>>>   // hacktacular Map > Set > Array morph to enable C-style looping
>>>   final foo = new String( myMap.entrySet().toArray()[i].value )
>>>
>>>   // do stuff with foo...
>>>
>>> }
>>>
>>>
>>> Nonetheless as mentioned in another part of the script I had no problem 
>>> using the shorter alternative, nor accessing keys and values using 
>>> *myMap.key* and *myMap.value*. Not sure what the difference is with my 
>>> more stubborn loop.
>>>
>>> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:



 Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>
> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>
>> There seem to be some arcane rules on how to iterate over some 
>> builtin Groovy/Java Types within a sandbox. I haven`t found a way 
>> that 
>> works without manually allowing the function.
>
>
> Which methods did you need to approve? We can easily add them to the 
> default whitelist in the Script Security plugin. But anyway
>
> The map`s each (at least)
  

>
>> 2) Serialization issues for iterators. 
>>
>
> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators 
> do not yet work (outside a `@NonCPS` method). Probably fixing them is not 
> hard, just have not gotten to it yet
>

 Yes, these issues I can very likely work around. For someone who is new 
 to Groovy and Jenkins sandboxing, a list of preferred methods would be 
 very 
 welcome (the examples from the workflow libs are rather simple). There are 
 atleast 3 different ways to iterate over containers, and several 
 variations 
 of those for maps.
  

>  
>
>>
>> take the createDList 
>> which seems to execute the code differently (throws errrors, need to 
>> define a explicit variable)
>>
>
> Not sure what this is about. If you find something you think should 
> work which does not work in a minimal reproducible script, please file a 
> bug report for it.
>
 Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
 Plugin? I was hoping for some feedback as I am not proficient in either of 
 those to pinpoint issues.
 The code above should be able to explain the issue, the exact same 
 method body in the node scope works fine, the call will result in some 
 message about "it not defined". Similary there seems some issues with name 
 clashes (if variables in functions are named like those in the node 
 scope), 
 but it mightve been some flukes during trial-and-error
  

>  
>
>>
>> Are variables from Closures global?
>>
>
> Local `def` var

Re: Pipelines, iterating maps and more headaches

[Patrick Wolf]

Did make use of the "Replay" feature at all to troubleshoot your script,
Norbert? Just curious.

https://jenkins.io/blog/2016/04/14/replay-with-pipeline/



On Wed, Apr 27, 2016 at 3:34 PM, Brian Ray  wrote:

> Nice hackaround. I will try that in the uncooperative parts of my script.
>
> Ah yes, *def x* vs *x*. On the face of it the two declarations should be
> identical--roughly typing *x* as an *Object*. But there are different
> scoping implications
> 
> for each.
>
>
> On Wednesday, April 27, 2016 at 3:00:43 PM UTC-7, Norbert Lange wrote:
>>
>> Hi Brian,
>>
>> every single method in the "final foo" - including the String
>> Constructor requires approval. I was hoping for a proper subset that would
>> work within the sandbox.
>> What I ended with (several dozen "Builds" later ) is using a helper
>> function squeezing the map into a list, seems the most sane aproach so far
>> =(
>>
>> Btw, whats the difference of using "def x" vs "x"?
>>
>> node {
>> 
>> for (it2 in mapToList(depmap)) {
>> name = it2[0]
>> revision = it2[1]
>> }
>> }
>> @NonCPS
>> def mapToList(depmap) {
>> def dlist = []
>> for (entry in depmap) {
>> dlist.add([entry.key, entry.value])
>> }
>> dlist
>> }
>>
>>
>>
>>
>> Am Mittwoch, 27. April 2016 18:26:51 UTC+2 schrieb Brian Ray:
>>>
>>> FWIW I recently replaced several C-style loops with *for ( x in y )*
>>> for iterating over both lists and maps in CPS code and for the most part
>>> conversion went fine. There were a couple of CPS sections where I could not
>>> use that construct and had to fall back on the C-loops and further do a
>>> torturous cast to avoid a serialization error getting keys and values from
>>> the map. I want to say *Set>* caused the exception
>>> because *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are
>>> serializable, while *Set *is not, per the JDK.
>>>
>>> for ( int i = 0; i < myMap.size(); i++ ) {
>>>
>>>   // hacktacular String() cloning to avoid NotSerializableException;
>>> also
>>>   // hacktacular Map > Set > Array morph to enable C-style looping
>>>   final foo = new String( myMap.entrySet().toArray()[i].value )
>>>
>>>   // do stuff with foo...
>>>
>>> }
>>>
>>>
>>> Nonetheless as mentioned in another part of the script I had no problem
>>> using the shorter alternative, nor accessing keys and values using
>>> *myMap.key* and *myMap.value*. Not sure what the difference is with my
>>> more stubborn loop.
>>>
>>> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:



 Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>
> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>
>> There seem to be some arcane rules on how to iterate over some
>> builtin Groovy/Java Types within a sandbox. I haven`t found a way
>> that
>> works without manually allowing the function.
>
>
> Which methods did you need to approve? We can easily add them to the
> default whitelist in the Script Security plugin. But anyway
>
> The map`s each (at least)


>
>> 2) Serialization issues for iterators.
>>
>
> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators
> do not yet work (outside a `@NonCPS` method). Probably fixing them is not
> hard, just have not gotten to it yet
>

 Yes, these issues I can very likely work around. For someone who is new
 to Groovy and Jenkins sandboxing, a list of preferred methods would be very
 welcome (the examples from the workflow libs are rather simple). There are
 atleast 3 different ways to iterate over containers, and several variations
 of those for maps.


>
>
>>
>> take the createDList
>> which seems to execute the code differently (throws errrors, need to
>> define a explicit variable)
>>
>
> Not sure what this is about. If you find something you think should
> work which does not work in a minimal reproducible script, please file a
> bug report for it.
>
 Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some
 Plugin? I was hoping for some feedback as I am not proficient in either of
 those to pinpoint issues.
 The code above should be able to explain the issue, the exact same
 method body in the node scope works fine, the call will result in some
 message about "it not defined". Similary there seems some issues with name
 clashes (if variables in functions are named like those in the node scope),
 but it mightve been some flukes during trial-and-error


>
>
>>
>> Are variables from Closures global?
>>
>
> Local `def` variables in a closure? Not sure what you are referring to
> here.
>
 See last point, and the code were I can access

Re: Pipelines, iterating maps and more headaches

[Brian Ray]

Nice hackaround. I will try that in the uncooperative parts of my script.

Ah yes, *def x* vs *x*. On the face of it the two declarations should be 
identical--roughly typing *x* as an *Object*. But there are different 
scoping implications 

 
for each.

On Wednesday, April 27, 2016 at 3:00:43 PM UTC-7, Norbert Lange wrote:
>
> Hi Brian,
>
> every single method in the "final foo" - including the String 
> Constructor requires approval. I was hoping for a proper subset that would 
> work within the sandbox.
> What I ended with (several dozen "Builds" later ) is using a helper 
> function squeezing the map into a list, seems the most sane aproach so far 
> =(
>
> Btw, whats the difference of using "def x" vs "x"?
>
> node {
> 
> for (it2 in mapToList(depmap)) {
> name = it2[0]
> revision = it2[1]
> }
> }
> @NonCPS
> def mapToList(depmap) {
> def dlist = []
> for (entry in depmap) {
> dlist.add([entry.key, entry.value])
> }
> dlist
> }
>
>
>
>
> Am Mittwoch, 27. April 2016 18:26:51 UTC+2 schrieb Brian Ray:
>>
>> FWIW I recently replaced several C-style loops with *for ( x in y )* for 
>> iterating over both lists and maps in CPS code and for the most part 
>> conversion went fine. There were a couple of CPS sections where I could not 
>> use that construct and had to fall back on the C-loops and further do a 
>> torturous cast to avoid a serialization error getting keys and values from 
>> the map. I want to say *Set>* caused the exception 
>> because *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are 
>> serializable, while *Set *is not, per the JDK.
>>
>> for ( int i = 0; i < myMap.size(); i++ ) {
>>   
>>   // hacktacular String() cloning to avoid NotSerializableException; 
>> also 
>>   // hacktacular Map > Set > Array morph to enable C-style looping
>>   final foo = new String( myMap.entrySet().toArray()[i].value )
>>
>>   // do stuff with foo...
>>
>> }
>>
>>
>> Nonetheless as mentioned in another part of the script I had no problem 
>> using the shorter alternative, nor accessing keys and values using 
>> *myMap.key* and *myMap.value*. Not sure what the difference is with my 
>> more stubborn loop.
>>
>> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>>>
>>>
>>>
>>> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:

 On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>
> There seem to be some arcane rules on how to iterate over some 
> builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
> works without manually allowing the function.


 Which methods did you need to approve? We can easily add them to the 
 default whitelist in the Script Security plugin. But anyway

 The map`s each (at least)
>>>  
>>>

> 2) Serialization issues for iterators. 
>

 `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do 
 not yet work (outside a `@NonCPS` method). Probably fixing them is not 
 hard, just have not gotten to it yet

>>>
>>> Yes, these issues I can very likely work around. For someone who is new 
>>> to Groovy and Jenkins sandboxing, a list of preferred methods would be very 
>>> welcome (the examples from the workflow libs are rather simple). There are 
>>> atleast 3 different ways to iterate over containers, and several variations 
>>> of those for maps.
>>>  
>>>
  

>
> take the createDList 
> which seems to execute the code differently (throws errrors, need to 
> define a explicit variable)
>

 Not sure what this is about. If you find something you think should 
 work which does not work in a minimal reproducible script, please file a 
 bug report for it.

>>> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
>>> Plugin? I was hoping for some feedback as I am not proficient in either of 
>>> those to pinpoint issues.
>>> The code above should be able to explain the issue, the exact same 
>>> method body in the node scope works fine, the call will result in some 
>>> message about "it not defined". Similary there seems some issues with name 
>>> clashes (if variables in functions are named like those in the node scope), 
>>> but it mightve been some flukes during trial-and-error
>>>  
>>>
  

>
> Are variables from Closures global?
>

 Local `def` variables in a closure? Not sure what you are referring to 
 here.

>>> See last point, and the code were I can access the it variable after the 
>>> closure were its used (Noted with "// Weird !" )
>>>

 The main problem you are presumably hitting is the well-known 
 JENKINS-26481 . We 
 are working on a fix, but in the meantime, do not use any method 

Re: Pipelines, iterating maps and more headaches

[Norbert Lange]

Hi Brian,

every single method in the "final foo" - including the String 
Constructor requires approval. I was hoping for a proper subset that would 
work within the sandbox.
What I ended with (several dozen "Builds" later ) is using a helper 
function squeezing the map into a list, seems the most sane aproach so far 
=(

Btw, whats the difference of using "def x" vs "x"?

node {

for (it2 in mapToList(depmap)) {
name = it2[0]
revision = it2[1]
}
}
@NonCPS
def mapToList(depmap) {
def dlist = []
for (entry in depmap) {
dlist.add([entry.key, entry.value])
}
dlist
}




Am Mittwoch, 27. April 2016 18:26:51 UTC+2 schrieb Brian Ray:
>
> FWIW I recently replaced several C-style loops with *for ( x in y )* for 
> iterating over both lists and maps in CPS code and for the most part 
> conversion went fine. There were a couple of CPS sections where I could not 
> use that construct and had to fall back on the C-loops and further do a 
> torturous cast to avoid a serialization error getting keys and values from 
> the map. I want to say *Set>* caused the exception because 
> *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are serializable, 
> while *Set *is not, per the JDK.
>
> for ( int i = 0; i < myMap.size(); i++ ) {
>   
>   // hacktacular String() cloning to avoid NotSerializableException; also 
>   // hacktacular Map > Set > Array morph to enable C-style looping
>   final foo = new String( myMap.entrySet().toArray()[i].value )
>
>   // do stuff with foo...
>
> }
>
>
> Nonetheless as mentioned in another part of the script I had no problem 
> using the shorter alternative, nor accessing keys and values using 
> *myMap.key* and *myMap.value*. Not sure what the difference is with my 
> more stubborn loop.
>
> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>>
>>
>>
>> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>>>
>>> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:

 There seem to be some arcane rules on how to iterate over some 
 builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
 works without manually allowing the function.
>>>
>>>
>>> Which methods did you need to approve? We can easily add them to the 
>>> default whitelist in the Script Security plugin. But anyway
>>>
>>> The map`s each (at least)
>>  
>>
>>>
 2) Serialization issues for iterators. 

>>>
>>> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do 
>>> not yet work (outside a `@NonCPS` method). Probably fixing them is not 
>>> hard, just have not gotten to it yet
>>>
>>
>> Yes, these issues I can very likely work around. For someone who is new 
>> to Groovy and Jenkins sandboxing, a list of preferred methods would be very 
>> welcome (the examples from the workflow libs are rather simple). There are 
>> atleast 3 different ways to iterate over containers, and several variations 
>> of those for maps.
>>  
>>
>>>  
>>>

 take the createDList 
 which seems to execute the code differently (throws errrors, need to 
 define a explicit variable)

>>>
>>> Not sure what this is about. If you find something you think should work 
>>> which does not work in a minimal reproducible script, please file a bug 
>>> report for it.
>>>
>> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
>> Plugin? I was hoping for some feedback as I am not proficient in either of 
>> those to pinpoint issues.
>> The code above should be able to explain the issue, the exact same method 
>> body in the node scope works fine, the call will result in some message 
>> about "it not defined". Similary there seems some issues with name clashes 
>> (if variables in functions are named like those in the node scope), but it 
>> mightve been some flukes during trial-and-error
>>  
>>
>>>  
>>>

 Are variables from Closures global?

>>>
>>> Local `def` variables in a closure? Not sure what you are referring to 
>>> here.
>>>
>> See last point, and the code were I can access the it variable after the 
>> closure were its used (Noted with "// Weird !" )
>>
>>>
>>> The main problem you are presumably hitting is the well-known 
>>> JENKINS-26481 . We 
>>> are working on a fix, but in the meantime, do not use any method built into 
>>> Groovy which takes a closure argument, such as `list.each {x -> …}` or 
>>> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on 
>>> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop 
>>> with an index.)
>>>
>> Could you please post me the preferable code for iterating a map in this 
>> way? (Not sure I fully understand the bug )
>>
>>
>>> Incidentally `it` does not currently work in closures as noted in 
>>> JENKINS-33468 
>>> 

Re: Jenkins building a product consisting of many Maven projects? (with Jenkins Pipeline plugin?)

[Karl Davis]

Prior to the pipeline/Jenkinsfile modus operandi, I would have done the 
following:

1. Created Jenkins "Maven project" jobs for each separate project, with 
triggers/hooks set to build them when changes are found.
2. Used the builtin triggers to "Build whenever a dependency changes" to 
handle the build chaining.

However, I haven't found any analogue for those builtin triggers in the 
pipeline world. Instead, I just add a manual trigger to my downstream jobs 
in the upstream Jenkinsfiles. Something like the following:

// ... actual build, above

stage 'Trigger Downstream' 
build job: '../some-downstream-project/master', wait: false

Perhaps someone else here has a better suggestion, but that's my current 
SOP.

On Monday, April 25, 2016 at 3:12:50 PM UTC-4, Marnix Klooster wrote:
>
> Hi all,
>
> (Apologies for crossposting my Stack Overflow question (
> http://stackoverflow.com/q/36624122/223837) here.)
>
> Basically my question is: how best to configure Jenkins for building a 
> product which consists of many interdependent Maven projects?
>
> So we have a large product, and which was divided into separate Maven 
> projects to keep it manageable.  But it is always released as a single 
> whole, so when one project is changed we like to build all dependent 
> projects down to the end product.
>
> Can the Jenkins Pipeline plug-in help us here?  We were thinking about 
> creating a single pom-file-depencency0analyzing job which would build the 
> Maven projects in the correct order.
>
> Thanks for any and all input!
>
> Groetjes,
>  <><
> Marnix
>

-- 
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/5b2e3b3e-25d9-48af-9e32-80f506c8b388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins v1.642.3

[Mark Waite]

I would guess that one or more of your jobs may have had their "Repository
browser" switched from one value to the first value in the list,
AssemblaWeb.  I don't know why that would happen, but I've seen it happen
at least a few times in my interactions with Jenkins and the git plugin.

Configure the job, and change the repository browser back to the type that
you want.

Mark Waite

On Wed, Apr 27, 2016 at 12:20 PM Ashish Yadav 
wrote:

> I am running Jenkins v.1642.3. I just saw the following in the Jenkins
> log. Any idea was causes this and how it can be resolved?
>
> Apr 27, 2016 12:51:47 PM WARNING 
> hudson.model.Descriptor$NewInstanceBindInterceptor instantiate
>
> falling back to default instantiation hudson.plugins.git.browser.AssemblaWeb 
> {"repoUrl":"","stapler-class":"hudson.plugins.git.browser.AssemblaWeb","$class":"hudson.plugins.git.browser.AssemblaWeb"}
> java.lang.IllegalArgumentException: Failed to instantiate class 
> hudson.plugins.git.browser.CGit from 
> {"repoUrl":"","stapler-class":"hudson.plugins.git.browser.AssemblaWeb","$class":"hudson.plugins.git.browser.AssemblaWeb"}
>   at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:602)
>   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
>   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:400)
>   at 
> hudson.plugins.git.browser.AssemblaWeb$AssemblaWebDescriptor.newInstance(AssemblaWeb.java:96)
>   at 
> hudson.plugins.git.browser.AssemblaWeb$AssemblaWebDescriptor.newInstance(AssemblaWeb.java:88)
>   at 
> hudson.model.Descriptor$NewInstanceBindInterceptor.instantiate(Descriptor.java:643)
>   at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:675)
>   at org.kohsuke.stapler.RequestImpl.access$200(RequestImpl.java:81)
>   at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:600)
>   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
>   at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:697)
>   at org.kohsuke.stapler.RequestImpl.access$200(RequestImpl.java:81)
>   at 
> org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:600)
>   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
>   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:400)
>   at hudson.model.Descriptor.newInstance(Descriptor.java:588)
>   at hudson.scm.SCMS.parseSCM(SCMS.java:64)
>   at hudson.model.AbstractProject.submit(AbstractProject.java:1871)
>   at hudson.maven.MavenModuleSet.submit(MavenModuleSet.java:1181)
>   at hudson.model.Job.doConfigSubmit(Job.java:1225)
>   at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:796)
>   at sun.reflect.GeneratedMethodAccessor1408.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)  
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
>   at 
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
>   at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
>   at 
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.st

Jenkins v1.642.3

[Ashish Yadav]

I am running Jenkins v.1642.3. I just saw the following in the Jenkins log. Any 
idea was causes this and how it can be resolved?


Apr 27, 2016 12:51:47 PM WARNING 
hudson.model.Descriptor$NewInstanceBindInterceptor instantiate

falling back to default instantiation hudson.plugins.git.browser.AssemblaWeb 
{"repoUrl":"","stapler-class":"hudson.plugins.git.browser.AssemblaWeb","$class":"hudson.plugins.git.browser.AssemblaWeb"}
java.lang.IllegalArgumentException: Failed to instantiate class 
hudson.plugins.git.browser.CGit from 
{"repoUrl":"","stapler-class":"hudson.plugins.git.browser.AssemblaWeb","$class":"hudson.plugins.git.browser.AssemblaWeb"}
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:602)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:400)
at 
hudson.plugins.git.browser.AssemblaWeb$AssemblaWebDescriptor.newInstance(AssemblaWeb.java:96)
at 
hudson.plugins.git.browser.AssemblaWeb$AssemblaWebDescriptor.newInstance(AssemblaWeb.java:88)
at 
hudson.model.Descriptor$NewInstanceBindInterceptor.instantiate(Descriptor.java:643)
at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:675)
at org.kohsuke.stapler.RequestImpl.access$200(RequestImpl.java:81)
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:600)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
at org.kohsuke.stapler.RequestImpl.instantiate(RequestImpl.java:697)
at org.kohsuke.stapler.RequestImpl.access$200(RequestImpl.java:81)
at 
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:600)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:404)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:400)
at hudson.model.Descriptor.newInstance(Descriptor.java:588)
at hudson.scm.SCMS.parseSCM(SCMS.java:64)
at hudson.model.AbstractProject.submit(AbstractProject.java:1871)
at hudson.maven.MavenModuleSet.submit(MavenModuleSet.java:1181)
at hudson.model.Job.doConfigSubmit(Job.java:1225)
at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:796)
at sun.reflect.GeneratedMethodAccessor1408.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)  at 
org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
at 
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at 
hudson.util.PluginServletFilter$1.doFilter(PluginServlet

Re: Pipelines, iterating maps and more headaches

[Brian Ray]

Side note: The map keys and values are simply *String*s.

On Wednesday, April 27, 2016 at 9:26:51 AM UTC-7, Brian Ray wrote:
>
> FWIW I recently replaced several C-style loops with *for ( x in y )* for 
> iterating over both lists and maps in CPS code and for the most part 
> conversion went fine. There were a couple of CPS sections where I could not 
> use that construct and had to fall back on the C-loops and further do a 
> torturous cast to avoid a serialization error getting keys and values from 
> the map. I want to say *Set>* caused the exception because 
> *AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are serializable, 
> while *Set *is not, per the JDK.
>
> for ( int i = 0; i < myMap.size(); i++ ) {
>   
>   // hacktacular String() cloning to avoid NotSerializableException; also 
>   // hacktacular Map > Set > Array morph to enable C-style looping
>   final foo = new String( myMap.entrySet().toArray()[i].value )
>
>   // do stuff with foo...
>
> }
>
>
> Nonetheless as mentioned in another part of the script I had no problem 
> using the shorter alternative, nor accessing keys and values using 
> *myMap.key* and *myMap.value*. Not sure what the difference is with my 
> more stubborn loop.
>
> On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>>
>>
>>
>> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>>>
>>> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:

 There seem to be some arcane rules on how to iterate over some 
 builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
 works without manually allowing the function.
>>>
>>>
>>> Which methods did you need to approve? We can easily add them to the 
>>> default whitelist in the Script Security plugin. But anyway
>>>
>>> The map`s each (at least)
>>  
>>
>>>
 2) Serialization issues for iterators. 

>>>
>>> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do 
>>> not yet work (outside a `@NonCPS` method). Probably fixing them is not 
>>> hard, just have not gotten to it yet
>>>
>>
>> Yes, these issues I can very likely work around. For someone who is new 
>> to Groovy and Jenkins sandboxing, a list of preferred methods would be very 
>> welcome (the examples from the workflow libs are rather simple). There are 
>> atleast 3 different ways to iterate over containers, and several variations 
>> of those for maps.
>>  
>>
>>>  
>>>

 take the createDList 
 which seems to execute the code differently (throws errrors, need to 
 define a explicit variable)

>>>
>>> Not sure what this is about. If you find something you think should work 
>>> which does not work in a minimal reproducible script, please file a bug 
>>> report for it.
>>>
>> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
>> Plugin? I was hoping for some feedback as I am not proficient in either of 
>> those to pinpoint issues.
>> The code above should be able to explain the issue, the exact same method 
>> body in the node scope works fine, the call will result in some message 
>> about "it not defined". Similary there seems some issues with name clashes 
>> (if variables in functions are named like those in the node scope), but it 
>> mightve been some flukes during trial-and-error
>>  
>>
>>>  
>>>

 Are variables from Closures global?

>>>
>>> Local `def` variables in a closure? Not sure what you are referring to 
>>> here.
>>>
>> See last point, and the code were I can access the it variable after the 
>> closure were its used (Noted with "// Weird !" )
>>
>>>
>>> The main problem you are presumably hitting is the well-known 
>>> JENKINS-26481 . We 
>>> are working on a fix, but in the meantime, do not use any method built into 
>>> Groovy which takes a closure argument, such as `list.each {x -> …}` or 
>>> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on 
>>> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop 
>>> with an index.)
>>>
>> Could you please post me the preferable code for iterating a map in this 
>> way? (Not sure I fully understand the bug )
>>
>>
>>> Incidentally `it` does not currently work in closures as noted in 
>>> JENKINS-33468 
>>> ;
>>>  
>>> use an explicit parameter name instead.
>>>
>> That seems to be one of the issues I am fighting with, and might be that 
>> the supposed name-clashes came from unfocused variations of the code. 
>> Strangely it does seem to somewhat work in the node body?
>>  
>> Kind Regards, 
>> Norbert 
>>
>

-- 
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..

Re: Pipelines, iterating maps and more headaches

[Brian Ray]

FWIW I recently replaced several C-style loops with *for ( x in y )* for 
iterating over both lists and maps in CPS code and for the most part 
conversion went fine. There were a couple of CPS sections where I could not 
use that construct and had to fall back on the C-loops and further do a 
torturous cast to avoid a serialization error getting keys and values from 
the map. I want to say *Set>* caused the exception because 
*AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are serializable, 
while *Set *is not, per the JDK.

for ( int i = 0; i < myMap.size(); i++ ) {
  
  // hacktacular String() cloning to avoid NotSerializableException; also 
  // hacktacular Map > Set > Array morph to enable C-style looping
  final foo = new String( myMap.entrySet().toArray()[i].value )

  // do stuff with foo...

}


Nonetheless as mentioned in another part of the script I had no problem 
using the shorter alternative, nor accessing keys and values using 
*myMap.key* and *myMap.value*. Not sure what the difference is with my more 
stubborn loop.

On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>
>
>
> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>>
>> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>>
>>> There seem to be some arcane rules on how to iterate over some 
>>> builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
>>> works without manually allowing the function.
>>
>>
>> Which methods did you need to approve? We can easily add them to the 
>> default whitelist in the Script Security plugin. But anyway
>>
>> The map`s each (at least)
>  
>
>>
>>> 2) Serialization issues for iterators. 
>>>
>>
>> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do 
>> not yet work (outside a `@NonCPS` method). Probably fixing them is not 
>> hard, just have not gotten to it yet
>>
>
> Yes, these issues I can very likely work around. For someone who is new to 
> Groovy and Jenkins sandboxing, a list of preferred methods would be very 
> welcome (the examples from the workflow libs are rather simple). There are 
> atleast 3 different ways to iterate over containers, and several variations 
> of those for maps.
>  
>
>>  
>>
>>>
>>> take the createDList 
>>> which seems to execute the code differently (throws errrors, need to 
>>> define a explicit variable)
>>>
>>
>> Not sure what this is about. If you find something you think should work 
>> which does not work in a minimal reproducible script, please file a bug 
>> report for it.
>>
> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
> Plugin? I was hoping for some feedback as I am not proficient in either of 
> those to pinpoint issues.
> The code above should be able to explain the issue, the exact same method 
> body in the node scope works fine, the call will result in some message 
> about "it not defined". Similary there seems some issues with name clashes 
> (if variables in functions are named like those in the node scope), but it 
> mightve been some flukes during trial-and-error
>  
>
>>  
>>
>>>
>>> Are variables from Closures global?
>>>
>>
>> Local `def` variables in a closure? Not sure what you are referring to 
>> here.
>>
> See last point, and the code were I can access the it variable after the 
> closure were its used (Noted with "// Weird !" )
>
>>
>> The main problem you are presumably hitting is the well-known 
>> JENKINS-26481 . We 
>> are working on a fix, but in the meantime, do not use any method built into 
>> Groovy which takes a closure argument, such as `list.each {x -> …}` or 
>> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on 
>> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop 
>> with an index.)
>>
> Could you please post me the preferable code for iterating a map in this 
> way? (Not sure I fully understand the bug )
>
>
>> Incidentally `it` does not currently work in closures as noted in 
>> JENKINS-33468 
>> ;
>>  
>> use an explicit parameter name instead.
>>
> That seems to be one of the issues I am fighting with, and might be that 
> the supposed name-clashes came from unfocused variations of the code. 
> Strangely it does seem to somewhat work in the node body?
>  
> Kind Regards, 
> Norbert 
>

-- 
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/53ef9445-93a4-42aa-885a-e5a5238758ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Pipeline Plugin - how to inject global passwords?

[Brian Ray]

Glad to help. Very good to know the differing behavior between freestyle 
and pipeline jobs.

On Wednesday, April 27, 2016 at 2:28:17 AM UTC-7, Harry G. wrote:
>
> Wow, this is strange!
> To be honest, my test case was a freestyle job and I assumed there should 
> be no difference.
> I tried again and it really works in pipeline, but not in freestyle job - 
> with exact same credential binding and same shell script!
>
> So I think this can help to fix JENKINS-24805
> So thanks a lot for bringing this up and sorry for the confusion!
>
> Am Dienstag, 26. April 2016 23:17:56 UTC+2 schrieb Brian Ray:
>>
>> Maybe my use case was different than JENKINS-24805.
>>
>> On Monday, April 25, 2016 at 4:54:14 AM UTC-7, Ant Weiss wrote:
>>>
>>> In fact I implemented this with Credentials Binding plugin and it worked 
>>> great - masking the passwords as it should.
>>>
>>>

-- 
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/c56852f8-32c9-4ea3-a7cc-f314512fffc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipelines, iterating maps and more headaches

[Norbert Lange]

Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>
> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>
>> There seem to be some arcane rules on how to iterate over some 
>> builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
>> works without manually allowing the function.
>
>
> Which methods did you need to approve? We can easily add them to the 
> default whitelist in the Script Security plugin. But anyway
>
> The map`s each (at least)
 

>
>> 2) Serialization issues for iterators. 
>>
>
> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do 
> not yet work (outside a `@NonCPS` method). Probably fixing them is not 
> hard, just have not gotten to it yet
>

Yes, these issues I can very likely work around. For someone who is new to 
Groovy and Jenkins sandboxing, a list of preferred methods would be very 
welcome (the examples from the workflow libs are rather simple). There are 
atleast 3 different ways to iterate over containers, and several variations 
of those for maps.
 

>  
>
>>
>> take the createDList 
>> which seems to execute the code differently (throws errrors, need to 
>> define a explicit variable)
>>
>
> Not sure what this is about. If you find something you think should work 
> which does not work in a minimal reproducible script, please file a bug 
> report for it.
>
Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some 
Plugin? I was hoping for some feedback as I am not proficient in either of 
those to pinpoint issues.
The code above should be able to explain the issue, the exact same method 
body in the node scope works fine, the call will result in some message 
about "it not defined". Similary there seems some issues with name clashes 
(if variables in functions are named like those in the node scope), but it 
mightve been some flukes during trial-and-error
 

>  
>
>>
>> Are variables from Closures global?
>>
>
> Local `def` variables in a closure? Not sure what you are referring to 
> here.
>
See last point, and the code were I can access the it variable after the 
closure were its used (Noted with "// Weird !" )

>
> The main problem you are presumably hitting is the well-known 
> JENKINS-26481 . We 
> are working on a fix, but in the meantime, do not use any method built into 
> Groovy which takes a closure argument, such as `list.each {x -> …}` or 
> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on 
> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop 
> with an index.)
>
Could you please post me the preferable code for iterating a map in this 
way? (Not sure I fully understand the bug )


> Incidentally `it` does not currently work in closures as noted in 
> JENKINS-33468 
> ;
>  
> use an explicit parameter name instead.
>
That seems to be one of the issues I am fighting with, and might be that 
the supposed name-clashes came from unfocused variations of the code. 
Strangely it does seem to somewhat work in the node body?
 
Kind Regards, 
Norbert 

-- 
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/c8a00b42-49e3-4152-a624-ff8bb0b0518a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

build trigger condition on checkin

[Hector Magnanao]

Hi,

I'm using Jenkins 1.625.2 on Windows and I was wondering if there was a way 
to trigger a build only on certain file types.  Right now my build runs on 
every checkin and I'd like to narrow it to down to a few type of checkins.

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/6893ad4d-a11d-45d2-a108-c62d76b50dd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipelines, iterating maps and more headaches

[Jesse Glick]

On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>
> There seem to be some arcane rules on how to iterate over some 
> builtin Groovy/Java Types within a sandbox. I haven`t found a way that 
> works without manually allowing the function.


Which methods did you need to approve? We can easily add them to the 
default whitelist in the Script Security plugin. But anyway


> 2) Serialization issues for iterators. 
>

`for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do not 
yet work (outside a `@NonCPS` method). Probably fixing them is not hard, 
just have not gotten to it yet.
 

>
> take the createDList 
> which seems to execute the code differently (throws errrors, need to 
> define a explicit variable)
>

Not sure what this is about. If you find something you think should work 
which does not work in a minimal reproducible script, please file a bug 
report for it.
 

>
> Are variables from Closures global?
>

Local `def` variables in a closure? Not sure what you are referring to here.

The main problem you are presumably hitting is the well-known JENKINS-26481 
. We are working on a 
fix, but in the meantime, do not use any method built into Groovy which 
takes a closure argument, such as `list.each {x -> …}` or 
`someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on 
the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop 
with an index.)

Incidentally `it` does not currently work in closures as noted in 
JENKINS-33468 ; use an 
explicit parameter name instead.

-- 
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/02dfacb5-935b-433e-aa75-e58cff069163%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying a builds parameters in a system Groovy script

[Samuel Almeida]

There is now  a replaceAction() where you can just pass a new action 
(Parameter) with the same name and it will replace it :)

http://javadoc.jenkins-ci.org/hudson/model/Actionable.html#replaceAction%28hudson.model.Action%29

On Friday, August 3, 2012 at 5:52:17 PM UTC+2, Reuben Gow wrote:
>
> Hi,
>
> I have a job that takes a number of parameters (version_number, 
> release_number, branch etc). This build can be built in a number of ways, 
> some need to get the values of these parameters from other locations. the 
> different modes are:
>
> 1) Manually - Take the passed in parameters
> 2) SCM Change - take the parameter values from the last successful build 
> of another job
> 3) Timer - take the parameter values from the last successful build of 
> another job
> 4) Upstream Job - take the parameters passed to it from the upstream job.
>
> 1 is obviously no problem, as is 4 with the use of the Parameterized build 
> plugin.
>
> I have written a Groovy script to retrieve the parameter values for cases 
> 2 and 3 but can't find a way to apply these values to the variables used in 
> the build step (execute shell ). I can create new parameters and access 
> these as variables but I don't really like this method as it makes my shell 
> script a bit ugly. 
>
> Does anyone know how to overwrite parameter values from within the Groovy 
> script.
>
> 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/71918569-5106-4173-a58a-1128c54379f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Changelog "Community ratings" not displayed

[Matthew.Webber]

>> It's a known issue. We just haven't had the time to restore this service 
>> between everything else going on right now.
No worries Daniel, I appreciate that things are busy at the moment.
Matthew


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-- 
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/6836E1DC2DDC174C9D64B7860E5AF5FCAC02051A%40EXCHMBX01.fed.cclrc.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: Changelog "Community ratings" not displayed

[Daniel Beck]

> On 27.04.2016, at 11:20, matthew.web...@diamond.ac.uk wrote:
> 
> If I go to the Jenkins Changelog page (new wiki version) at 
> https://jenkins.io/changelog/, and click "Community ratings", I do _not_ see 
> the individual ratings for each release. I tried using a number of different 
> browsers on different OSes.
> 
> Does anyone else have this problem?

It's a known issue. We just haven't had the time to restore this service 
between everything else going on right now.

-- 
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/D05FF3AE-FEB5-4E47-B946-D522E3195133%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: How to MaskPasswordsBuildWrapper in DSL?

[thomas . lehmann]

In addition to mention:

The "Snippet Generator" provides documentation on this:

*Password Parameter*s, or any other type of build parameters selected for 
masking in Hudson's/Jenkins' main configuration screen (*Manage Hudson* > 
*Configure 
System*), will be automatically masked.

And also provide code generation. Even with specifying in the job
a name and a password doesn't work:

wrap([$class: 'MaskPasswordsBuildWrapper', varPasswordPairs: 
[[password: '4567', var: 'BAR']]]) {
echo "BAR=${BAR}"
echo "FOO=${FOO}"
}

Result:

groovy.lang.MissingPropertyException: No such property: BAR for class: 
WorkflowScript
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)






On Wednesday, April 27, 2016 at 11:31:15 AM UTC+2, thomas@teamaol.com 
wrote:
>
> I created a masked password FOO with "1234".
> Here my simple test DSL script:
>
> node {
> stage "ONE"
>
> wrap([$class: 'MaskPasswordsBuildWrapper']) {
> echo "FOO=${FOO}"
> }
> }
>
> Independent whether I check "Prepare an environment for the run" or not 
> ...
> I get this:
>
> groovy.lang.MissingPropertyException: No such property: FOO for class: 
> WorkflowScript
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)
>
>
> Most probably I'm using it the wrong way.
> Could you please help on this?
>
> Regards,
> 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/beed4e52-0c25-4304-9148-80f4b3c5e17c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to MaskPasswordsBuildWrapper in DSL?

[thomas . lehmann]

I created a masked password FOO with "1234".
Here my simple test DSL script:

node {
stage "ONE"
   
wrap([$class: 'MaskPasswordsBuildWrapper']) {
echo "FOO=${FOO}"
}
}

Independent whether I check "Prepare an environment for the run" or not ...
I get this:

groovy.lang.MissingPropertyException: No such property: FOO for class: 
WorkflowScript
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)


Most probably I'm using it the wrong way.
Could you please help on this?

Regards,
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/433c8b4e-7e35-4fa1-a203-cad4e53acaf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Pipeline Plugin - how to inject global passwords?

[Harry G.]

Wow, this is strange!
To be honest, my test case was a freestyle job and I assumed there should 
be no difference.
I tried again and it really works in pipeline, but not in freestyle job - 
with exact same credential binding and same shell script!

So I think this can help to fix JENKINS-24805
So thanks a lot for bringing this up and sorry for the confusion!

Am Dienstag, 26. April 2016 23:17:56 UTC+2 schrieb Brian Ray:
>
> Maybe my use case was different than JENKINS-24805.
>
> On Monday, April 25, 2016 at 4:54:14 AM UTC-7, Ant Weiss wrote:
>>
>> In fact I implemented this with Credentials Binding plugin and it worked 
>> great - masking the passwords as it should.
>>
>>

-- 
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/6c58b865-011f-470f-a28b-d27dfbff7100%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Changelog "Community ratings" not displayed

[Matthew.Webber]

If I go to the Jenkins Changelog page (new wiki version) at 
https://jenkins.io/changelog/, and click "Community ratings", I do _not_ see 
the individual ratings for each release. I tried using a number of different 
browsers on different OSes.

Does anyone else have this problem?

Thanks
Matthew


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

-- 
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/6836E1DC2DDC174C9D64B7860E5AF5FCAC01F3B7%40EXCHMBX01.fed.cclrc.ac.uk.
For more options, visit https://groups.google.com/d/optout.