Re: LTS upgrade 2.204.5 > 2.222.3 ClassNotFoundException on JnlpProtocol1Handler

[Brian Ray]

As luck would have it I re-upgraded without issue. No recurrence of the 
protocol handler classload exception.

But in the meantime I did hit upon a logging configuration that might have 
pointed to the culprit. Here's a logging.properties file you can feed to 
Jenkins via the method at the end of this wiki page 
<https://www.jenkins.io/doc/book/system-administration/viewing-logs/>. My 
suspicion is that using the *System Log* link would not work in the 
situation I ran into because the stack trace blocked logon outright. You 
would never be able to get back to the custom logger(s) set up in the UI.

handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler

.level=WARNING

java.util.logging.FileHandler.level=FINE
java.util.logging.FileHandler.pattern=c:/Jenkins/troubleshoot%g.log
java.util.logging.FileHandler.limit=1048576
java.util.logging.FileHandler.count=10
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

java.util.logging.ConsoleHandler.level=WARNING
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

java.util.logging.SimpleFormatter.format=[%1$tF %1$tT %1$tz] [%4$s] %2$s %5
$s%6$s%n

jenkins.InitReactorRunner.level=FINE
hudson.ExtensionFinder$GuiceFinder.level=FINE



On Monday, May 4, 2020 at 9:57:46 AM UTC-7, Brian Ray wrote:
>
> On upgrade of our production LTS core from 2.204.5 to 2.222.3 the master 
> UI stack traced immediately thus, not even displaying logon fields.
>
> java.lang.ClassNotFoundException: 
> org.jenkinsci.remoting.engine.JnlpProtocol1Handler ...
>
> Full stack trace is down at the end.
>
> I understand the proximate cause. Deprecated protocols JNLP 1 through 3 
> were removed in Remoting 3.40 
> <https://github.com/jenkinsci/remoting/releases/tag/remoting-3.40> (core 
> 2.222.1).
>
> After rollback of the core I'm stuck in troubleshooting the ultimate 
> cause. I am reasonably certain that I upgraded all JNLP agents to protocol 
> 4 circa core 2.138.1. Our WMI Windows Agents Plugin is up to date at 
> version 1.6. A quick and dirty Script Console query shows all our online 
> Windows agents connected with protocol 4.
>
> So ...
>
> 1. Is it possible that some other plugin is looking for this JNLP 1 class?
> 2. Is it possible that a node running an old agent JAR is trying to 
> connect via JNLP 1?
> 3. And most importantly, how could I squeeze more information out of the 
> reactor startup processing to find the culprit(s)? Are there some loggers 
> that might cough up that information with more verbose logging?
>
> Thanks!
>
> ---
>
> java.lang.ClassNotFoundException: 
> org.jenkinsci.remoting.engine.JnlpProtocol1Handler
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:543)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> Caused: java.lang.NoClassDefFoundError: 
> Lorg/jenkinsci/remoting/engine/JnlpProtocol1Handler;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
> at java.lang.Class.getDeclaredFields(Class.java:1916)
> at 
> com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:675)
> at 
> com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:380)
> at 
> com.google.inject.internal.MembersInjectorStore.createWithListeners(MembersInjectorStore.java:93)
> at 
> com.google.inject.internal.MembersInjectorStore.access$000(MembersInjectorStore.java:37)
> at 
> com.google.inject.internal.MembersInjectorStore$1.create(MembersInjectorStore.java:45)
> at 
> com.google.inject.internal.MembersInjectorStore$1.create(MembersInjectorStore.java:42)
> at 
> com.google.inject.internal.FailableCache$1.load(FailableCache.java:37)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568)
> at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
> Caused: com.google.common.util.concurrent.ExecutionError
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3969)
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4829)
> at 
> com.google.common.c

LTS upgrade 2.204.5 > 2.222.3 ClassNotFoundException on JnlpProtocol1Handler

[Brian Ray]

On upgrade of our production LTS core from 2.204.5 to 2.222.3 the master UI 
stack traced immediately thus, not even displaying logon fields.

java.lang.ClassNotFoundException: 
org.jenkinsci.remoting.engine.JnlpProtocol1Handler ...

Full stack trace is down at the end.

I understand the proximate cause. Deprecated protocols JNLP 1 through 3 
were removed in Remoting 3.40 
 (core 
2.222.1).

After rollback of the core I'm stuck in troubleshooting the ultimate cause. 
I am reasonably certain that I upgraded all JNLP agents to protocol 4 circa 
core 2.138.1. Our WMI Windows Agents Plugin is up to date at version 1.6. A 
quick and dirty Script Console query shows all our online Windows agents 
connected with protocol 4.

So ...

1. Is it possible that some other plugin is looking for this JNLP 1 class?
2. Is it possible that a node running an old agent JAR is trying to connect 
via JNLP 1?
3. And most importantly, how could I squeeze more information out of the 
reactor startup processing to find the culprit(s)? Are there some loggers 
that might cough up that information with more verbose logging?

Thanks!

---

java.lang.ClassNotFoundException: 
org.jenkinsci.remoting.engine.JnlpProtocol1Handler
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at 
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:543)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
Caused: java.lang.NoClassDefFoundError: 
Lorg/jenkinsci/remoting/engine/JnlpProtocol1Handler;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredFields(Class.java:1916)
at 
com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:675)
at 
com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:380)
at 
com.google.inject.internal.MembersInjectorStore.createWithListeners(MembersInjectorStore.java:93)
at 
com.google.inject.internal.MembersInjectorStore.access$000(MembersInjectorStore.java:37)
at 
com.google.inject.internal.MembersInjectorStore$1.create(MembersInjectorStore.java:45)
at 
com.google.inject.internal.MembersInjectorStore$1.create(MembersInjectorStore.java:42)
at 
com.google.inject.internal.FailableCache$1.load(FailableCache.java:37)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
Caused: com.google.common.util.concurrent.ExecutionError
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232)
at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3969)
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4829)
at 
com.google.common.cache.LocalCache$LocalManualCache.getUnchecked(LocalCache.java:4834)
at com.google.inject.internal.FailableCache.get(FailableCache.java:48)
at 
com.google.inject.internal.MembersInjectorStore.get(MembersInjectorStore.java:68)
at 
com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:74)
at 
com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29)
at 
com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37)
at 
com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33)
at 
com.google.inject.internal.FailableCache$1.load(FailableCache.java:37)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
Caused: com.google.common.util.concurrent.ExecutionError
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232)
at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3969)
at 
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4829)
at 
com.google.common.cache.LocalCache$LocalManualCache.getUnchecked(LocalCache.java:4834)
at com.google.inject.internal.FailableCache.get(FailableCache.java:48)
at 
com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:50)

Re: Locking multiple stages with NODE_NAME based lock

[Brian Ray]

Now I understand. I had not considered locking a particular node for re-use 
in the same job. There must be some way to pin the node even if it is freed 
up. I will try to think of a solution.

On Wednesday, April 3, 2019 at 7:05:34 PM UTC-7, Dusan Nikolov wrote:
>
> Hi Brian,
>
> I think lock works within steps and script block, however this doesn't 
> help me. I need bigger to lock a node across several sequential stages to 
> prevent it from being freed.
>
> This is the use case:
> Node1 and Node2 start working their parts of a stage in parallel. Parallel 
> stages is used to, well parallelize workflow. End of first parallel block 
> is a synchronization point (end of setup phase).
> After this, nodes go into the second parallel block, where they do the 
> testing (testing involves both nodes as a unit).
>
> Nodes can finish phase1 at different speeds, and due to this Jenkins makes 
> the node that is waiting on the other one available for other jobs 
> (including a queued run of this same job). I want to prevent it from being 
> available.
>
> I hope I explained my use case more closely now.
>
> On Sun, Mar 24, 2019, 10:11 AM Brian Ray  > wrote:
>
>> I just made a suggestion on a similar thread 
>> <https://groups.google.com/d/msg/jenkinsci-users/41bKAIfrPAw/zpuyg__7AAAJ>. 
>> Does lock work inside a steps block? Or a script block? It seems like it 
>> should, because it is a step that does something imperatively.
>>
>> On Thursday, March 7, 2019 at 3:58:59 PM UTC-8, Dusan Nikolov wrote:
>>>
>>> Hi, 
>>> I'm trying to figure out how/if it's possible to create a lock that will 
>>> guard multiple stages of a pipeline execution, based on the NODE_NAME on 
>>> which they are supposed to execute.
>>>
>>> I tried putting the lock in the options block of the surrounding stage, 
>>> but this throws an error because options block in a stage is 
>>> executed/evaluated before agent block.
>>> Please see the example pipeline below for reference:
>>>
>>> pipeline {
>>> agent none
>>> stages {
>>> stage ('main') {
>>> parallel {
>>> stage ('server') {
>>> agent { label 'server' }
>>> // options { lock(NODE_NAME) }
>>> stages {
>>> stage ('all') {
>>> options { lock("${NODE_NAME}") } // this also seems to fail
>>> steps {
>>> script {
>>> echo "${NODE_NAME}"
>>> sleep(10)
>>> }
>>> }
>>> }
>>> }
>>> }
>>> stage ('client') {
>>> agent { label 'client' }
>>> stages {
>>> stage ('all') {
>>> options { lock("${NODE_NAME}") }
>>> steps {
>>> script {
>>> echo "${NODE_NAME}"
>>> sleep(10)
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-users/Jlhy1hxe92M/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/0e87d972-12b5-4b51-ae2d-7f269f417b5a%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/0e87d972-12b5-4b51-ae2d-7f269f417b5a%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/d1103e8c-d6e0-4dc2-b6dd-c70786a18317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Locking multiple stages with NODE_NAME based lock

[Brian Ray]

I just made a suggestion on a similar thread 
. 
Does lock work inside a steps block? Or a script block? It seems like it 
should, because it is a step that does something imperatively.

On Thursday, March 7, 2019 at 3:58:59 PM UTC-8, Dusan Nikolov wrote:
>
> Hi, 
> I'm trying to figure out how/if it's possible to create a lock that will 
> guard multiple stages of a pipeline execution, based on the NODE_NAME on 
> which they are supposed to execute.
>
> I tried putting the lock in the options block of the surrounding stage, 
> but this throws an error because options block in a stage is 
> executed/evaluated before agent block.
> Please see the example pipeline below for reference:
>
> pipeline {
> agent none
> stages {
> stage ('main') {
> parallel {
> stage ('server') {
> agent { label 'server' }
> // options { lock(NODE_NAME) }
> stages {
> stage ('all') {
> options { lock("${NODE_NAME}") } // this also seems to fail
> steps {
> script {
> echo "${NODE_NAME}"
> sleep(10)
> }
> }
> }
> }
> }
> stage ('client') {
> agent { label 'client' }
> stages {
> stage ('all') {
> options { lock("${NODE_NAME}") }
> steps {
> script {
> echo "${NODE_NAME}"
> sleep(10)
> }
> }
> }
> }
> }
> }
> }
> }
> }
>

-- 
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/0e87d972-12b5-4b51-ae2d-7f269f417b5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to prevent concurrent execution of jobs on the same node, but allow a few parallel steps execution?

[Brian Ray]

Can you put your lock step inside a step block? We still use Imperative 
Pipeline so I'm less familiar with Declarative Pipeline. But it seems like 
inside a step block that NODE_NAME should resolve correctly, because--I 
think--the block is running in a node context.

On Monday, February 11, 2019 at 5:33:44 AM UTC-8, Vitaly Karasik wrote:
>
> I started to play with the lockable resources plugin. 
> I'd like to prevent parallel execution of my pipeline (multibranch 
> pipeline) on the same Jenkins slave, so I tried to use "$NODE_NAME" as 
> lockable resource, like this:
>
> pipeline {
>   agent { label 'slave-parallel' }
>   options {
> lock ("${NODE_NAME}")
>}
>
> stages() 
> {
> ..
> }
>
> But unfortunately $NODE_NAME isn't available on this step. Is there simple 
> workaround for thaT? 
>
> On Thursday, January 31, 2019 at 11:43:30 AM UTC+2, Daniel Butler wrote:
>>
>> You could use the lockable resources plugin (v2.2+):
>>
>> Set up a single resource for each node and give them all a common label
>>
>> Then your Jenkinsfile would be:
>>
>> lock(label: "common-label", variable: "LOCKED_NODE"){
>> node(env.LOCKED_NODE){
>> //build project
>> }
>> }
>>
>> Regards,
>> Daniel.
>>
>> On Thu, Jan 31, 2019 at 7:48 AM Vitaly Karasik  wrote:
>>
>>> I'd like to mark *whole* pipeline job as throttling resource; and unlike 
>>> freestyle jobs, Throttleling plugin does't know to do that. I.e. I cannot 
>>> use "throttle" in pipeline options.
>>>
>>> On Wednesday, January 30, 2019 at 7:47:20 PM UTC+2, Den Slobozhanskyi 
>>> wrote:

 Just to clarify - does it mean that Throttling plugin throttles not the 
 job as a whole, but each step in parallel? My assumption was that 
 throttling is only for the job, and nested threads have nothing to do with 
 throttle. By your words it looks like setting throttling to "1" for the 
 job 
 reduce the possible parallel threads execution to a single thread at a 
 time 
 as well, is that true?

 If this is not true, you just gather all the jobs under one throttling 
 category and set the concurrent builds limit to 1.

 BR,
 Denys

 среда, 30 января 2019 г., 14:17:15 UTC+1 пользователь Vitaly Karasik 
 написал:
>
> I have multibranch job, whole pipeline runs on certain node. 
>
> Currently I have a slaves with single executor, so multiple jobs 
> cannot run on the same node. I'd like to use parallel steps inside my 
> pipeline, so I need to increase number of executors. 
>
> What is the best way to prevent concurrent job execution? 
>
> Such configuration was trivial with Jenkins freestyle job and 
> Throttling plugin - I simple used "Maximum Concurrent Builds Per Node". 
> But 
> in pipeline it seems that I cannot use "throttle" for whole pipeline, I 
> need to use it for each step. Is there more elegant solution?
>
> TIA, Vitaly
>
 -- 
>>> 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/d6b76faf-f9e6-4960-8dc5-ab79c6c6ac0f%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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/d54117cb-3251-4cca-9f98-50b8887fc2de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to prevent concurrent execution of jobs on the same node, but allow a few parallel steps execution?

[Brian Ray]

Can you put your lock step inside a steps block? We still use Imperative 
Pipeline so I'm less familiar with Declarative Pipeline. But it seems like 
inside a step block that NODE_NAME should resolve correctly, because--I 
think--the block is running in a node context.

On Monday, February 11, 2019 at 5:33:44 AM UTC-8, Vitaly Karasik wrote:
>
> I started to play with the lockable resources plugin. 
> I'd like to prevent parallel execution of my pipeline (multibranch 
> pipeline) on the same Jenkins slave, so I tried to use "$NODE_NAME" as 
> lockable resource, like this:
>
> pipeline {
>   agent { label 'slave-parallel' }
>   options {
> lock ("${NODE_NAME}")
>}
>
> stages() 
> {
> ..
> }
>
> But unfortunately $NODE_NAME isn't available on this step. Is there simple 
> workaround for thaT? 
>
> On Thursday, January 31, 2019 at 11:43:30 AM UTC+2, Daniel Butler wrote:
>>
>> You could use the lockable resources plugin (v2.2+):
>>
>> Set up a single resource for each node and give them all a common label
>>
>> Then your Jenkinsfile would be:
>>
>> lock(label: "common-label", variable: "LOCKED_NODE"){
>> node(env.LOCKED_NODE){
>> //build project
>> }
>> }
>>
>> Regards,
>> Daniel.
>>
>> On Thu, Jan 31, 2019 at 7:48 AM Vitaly Karasik  wrote:
>>
>>> I'd like to mark *whole* pipeline job as throttling resource; and unlike 
>>> freestyle jobs, Throttleling plugin does't know to do that. I.e. I cannot 
>>> use "throttle" in pipeline options.
>>>
>>> On Wednesday, January 30, 2019 at 7:47:20 PM UTC+2, Den Slobozhanskyi 
>>> wrote:

 Just to clarify - does it mean that Throttling plugin throttles not the 
 job as a whole, but each step in parallel? My assumption was that 
 throttling is only for the job, and nested threads have nothing to do with 
 throttle. By your words it looks like setting throttling to "1" for the 
 job 
 reduce the possible parallel threads execution to a single thread at a 
 time 
 as well, is that true?

 If this is not true, you just gather all the jobs under one throttling 
 category and set the concurrent builds limit to 1.

 BR,
 Denys

 среда, 30 января 2019 г., 14:17:15 UTC+1 пользователь Vitaly Karasik 
 написал:
>
> I have multibranch job, whole pipeline runs on certain node. 
>
> Currently I have a slaves with single executor, so multiple jobs 
> cannot run on the same node. I'd like to use parallel steps inside my 
> pipeline, so I need to increase number of executors. 
>
> What is the best way to prevent concurrent job execution? 
>
> Such configuration was trivial with Jenkins freestyle job and 
> Throttling plugin - I simple used "Maximum Concurrent Builds Per Node". 
> But 
> in pipeline it seems that I cannot use "throttle" for whole pipeline, I 
> need to use it for each step. Is there more elegant solution?
>
> TIA, Vitaly
>
 -- 
>>> 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/d6b76faf-f9e6-4960-8dc5-ab79c6c6ac0f%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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/7eabfb51-9587-41c8-a40e-7fdbc9f92416%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Active Directory plugin warning: TLS is not correctly configured

[Brian Ray]

Regarding the TRUST_ALL_CERTIFICATES option disappearing from the Global 
Security settings: If your master is on Windows you might have run into 
JENKINS-56224 . We did 
so on a recent upgrade to from AD ~2.10 to AD 2.12. Though the underlying 
setting was still present in the settings file.

On Tuesday, January 29, 2019 at 2:17:12 PM UTC-8, Andreas Goeb wrote:
>
> Dear fellow Jenkins users, 
>
> I came across an issue today that I just cannot figure out myself. I hope 
> this is the correct place to ask for help. 
>
> *Problem:* 
>
> After some connection issues with Active Directory and following 
> reconfiguration, Jenkins now shows the warning „TLS is not correctly 
> configured on Active Directory plugin.Please, change to a more secured 
> option;" 
>
> *Environment:* 
>
> When the issue occurred for the first time this morning, I was using 
> Jenkins 2.150.2 with Active Directory plugin 2.11 and the following 
> settings 
>
> - StartTLS: true 
> - TRUST_ALL_CERTIFICATES 
>
> *What I did so far:* 
>
> I thought the reason for the warning might be the TRUST_ALL_CERTIFICATES 
> option, so I tried to disable it. However, it is not shown in the Global 
> Security settings anymore, nor is it contained in the settings.xml file. 
> So, I followed the plugin's documentation wiki page and performed the 
> following steps for proper TLS/LDAPS configuration: 
>
> - set the 
> hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true 
> system property 
> - change the domain controller port in the plugin’s settings to 3269 
> - copy the JVM’s „cacerts" trust store and import the server certificate 
> into the copy 
> - set the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword 
> system properties to point to the copy 
> - configure a custom logger for ActiveDirectorySecurityRealm and log level 
> FINER 
>
> The log now shows successful LDAPS connections over port 3269, and users 
> can log in. However, the warning about insecure TLS configuration is still 
> shown. 
>
> Does any of you know what the reason for the warning may be and which 
> configuration I might still have to change? 
>
> Thanks a lot, 
> Andreas

-- 
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/b270a75b-a06d-417d-a9c3-ac9e32d3f626%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Matrix-auth & Folders] How to properly restrict a user to get access only to a job in a (sub)folder

[Brian Ray]

My tired eyes. I just re-read the subject line mentioning Matrix Auth.

I do recommend "upgrading" from Matrix Auth to Role Strategy. That 
eliminated a lot of pain for us we accumulated more folders, jobs, and 
users. And that could eliminate at least one bit of complexity in your use 
case. Though beware, you still need to create read-access roles to the 
folders and separate roles to the jobs inside the folders.

The advantage is twofold though: 1) You tailor ACLs to roles instead of 
individual users. 2) The pattern-matching nature of the roles can give you 
the ability to apply the role to multiple folders and jobs.

On Sunday, March 24, 2019 at 9:05:25 AM UTC-7, Brian Ray wrote:
>
> I'm guessing you use the Role Strategy 
> <https://plugins.jenkins.io/role-strategy> plugin. We use it with the Active 
> Directory <https://plugins.jenkins.io/active-directory> plugin for 
> authentication. To make a long story short I don't think there's a way, at 
> least with Role Strategy, to set up an ACL hierarchy. We have had to set up 
> multiple roles (ACLs) on the folders and then on jobs.
>
> The one labor-saving grace is that via AD groups we've been able to assign 
> roles to groups instead of individual users. Sometimes we do give 
> individual users special privileges and in that sense we get some small bit 
> of hierarchical effect. But by virtue of user membership in AD groups, not 
> via some relationship between the the roles targeting folders and jobs.
>
> If you come across a solution I'd be curious to learn of it.
>
> Good luck.
>
> On Wednesday, January 16, 2019 at 5:33:01 AM UTC-8, geoffroy...@gmail.com 
> wrote:
>>
>> Hello
>> any suggestion to move forward on this topic?
>> Thanks in advance
>>
>> On Thursday, 20 December 2018 18:13:18 UTC+1, geoffroy...@gmail.com 
>> wrote:
>>>
>>> Hello
>>>
>>> i'm a bit struggling for one use case i have, maybe someone could share 
>>> its experience on such scenario.
>>>
>>> *Jobs structure:*
>>>
>>>- FolderA
>>>- SubFolderA
>>>  - jobA1
>>>  - jobA2
>>>   - SubFolderB
>>>  - jobB1
>>>   
>>>
>>> *Use caseq:*
>>>
>>>1. user1 has read access to all jobs
>>>2. user2 has only read access to jobA2
>>>
>>>
>>> By default, authorizations are inherited from parent ACL. It is very 
>>> handy to avoid redefining all authorizations for each item level.
>>> However, i am not able to find a way to keep this inherited behavior 
>>> while granting some authorizations at lower (job) level.
>>>
>>>- If i configure user1 authorization at FolderA level, then with 
>>>inheritance it will have access to everything
>>>- If i configure user2 authorization at jobA2 level, then it cannot 
>>>access jobA2 because upper-level authorizations are not defined (ie. 
>>> user2 
>>>does not have access to FolderA & SubFolderA)
>>>
>>> Is there a way to address those 2 scenarios while still relying on 
>>> inheritance to ease authorization definitions? If not, does it means i have 
>>> to redefine at each level all authorizations (ie. no parent ACL 
>>> inheritance) to achieve that?
>>>
>>> What about an implicit "Folder PassThrough" authorization that would be 
>>> automatically granted to all parents items when authorizing a user to 
>>> access a lower-level item?
>>> In that case, if i configure user2 authorization at jobA2 level, then it 
>>> could "PassThrough" FolderA and SubFolderA and eventually get access to 
>>> jobA2 on the UI.
>>>
>>> Not sure if it is clear, anyway any help will be appreciated ;)
>>> BR
>>>
>>

-- 
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/466345a9-886c-4aab-9e8e-cfb8c5c1ca99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Matrix-auth & Folders] How to properly restrict a user to get access only to a job in a (sub)folder

[Brian Ray]

I'm guessing you use the Role Strategy 
 plugin. We use it with the Active 
Directory  plugin for 
authentication. To make a long story short I don't think there's a way, at 
least with Role Strategy, to set up an ACL hierarchy. We have had to set up 
multiple roles (ACLs) on the folders and then on jobs.

The one labor-saving grace is that via AD groups we've been able to assign 
roles to groups instead of individual users. Sometimes we do give 
individual users special privileges and in that sense we get some small bit 
of hierarchical effect. But by virtue of user membership in AD groups, not 
via some relationship between the the roles targeting folders and jobs.

If you come across a solution I'd be curious to learn of it.

Good luck.

On Wednesday, January 16, 2019 at 5:33:01 AM UTC-8, geoffroy...@gmail.com 
wrote:
>
> Hello
> any suggestion to move forward on this topic?
> Thanks in advance
>
> On Thursday, 20 December 2018 18:13:18 UTC+1, geoffroy...@gmail.com wrote:
>>
>> Hello
>>
>> i'm a bit struggling for one use case i have, maybe someone could share 
>> its experience on such scenario.
>>
>> *Jobs structure:*
>>
>>- FolderA
>>- SubFolderA
>>  - jobA1
>>  - jobA2
>>   - SubFolderB
>>  - jobB1
>>   
>>
>> *Use caseq:*
>>
>>1. user1 has read access to all jobs
>>2. user2 has only read access to jobA2
>>
>>
>> By default, authorizations are inherited from parent ACL. It is very 
>> handy to avoid redefining all authorizations for each item level.
>> However, i am not able to find a way to keep this inherited behavior 
>> while granting some authorizations at lower (job) level.
>>
>>- If i configure user1 authorization at FolderA level, then with 
>>inheritance it will have access to everything
>>- If i configure user2 authorization at jobA2 level, then it cannot 
>>access jobA2 because upper-level authorizations are not defined (ie. 
>> user2 
>>does not have access to FolderA & SubFolderA)
>>
>> Is there a way to address those 2 scenarios while still relying on 
>> inheritance to ease authorization definitions? If not, does it means i have 
>> to redefine at each level all authorizations (ie. no parent ACL 
>> inheritance) to achieve that?
>>
>> What about an implicit "Folder PassThrough" authorization that would be 
>> automatically granted to all parents items when authorizing a user to 
>> access a lower-level item?
>> In that case, if i configure user2 authorization at jobA2 level, then it 
>> could "PassThrough" FolderA and SubFolderA and eventually get access to 
>> jobA2 on the UI.
>>
>> Not sure if it is clear, anyway any help will be appreciated ;)
>> BR
>>
>

-- 
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/e1cecde5-ea39-4f9b-99ef-0212488cb20f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting Jgit exception in a Job that uses native Git

[Brian Ray]

No problem on top posting. It seems to be the default behavior of the 
Groups UI here, so I am guilty of it too.

I misunderstood or otherwise skipped right over the "native" modifier in 
your original post. I wonder if there is some path through the plugin code 
that utilizes parts of JGit even when the job specifies checkout via the 
regular Git client. Very strange.

On Monday, May 14, 2018 at 12:18:00 AM UTC-7, Dirk Heinrichs wrote:
>
> Hi,
>
>  
>
> how could I have selected a native Git installation in the job config if 
> it wasn't in the global config?
>
>  
>
> Bye...
>
>  
>
> Dirk
>
>  
>
> PS: Sorry for top posting, I'm currently forced to use Outlook.
>
>  
>
>  
>
> *From:* jenkins...@googlegroups.com  [mailto:
> jenkins...@googlegroups.com ] *On Behalf Of *Brian Ray
> *Sent:* Freitag, 11. Mai 2018 02:21
> *To:* Jenkins Users <jenkins...@googlegroups.com >
> *Subject:* Re: Getting Jgit exception in a Job that uses native Git
>
>  
>
> Navigate to *Manage Jenkins* > *Global Tool Configuration* > *Git* > *Git 
> Installations*.
>
> If the only installation configured there is *JGit *or *JGit with Apache 
> HTTP client*, that is the answer. The *Git *installation will probably be 
> what you are looking for.
>
> On Friday, March 23, 2018 at 4:21:32 AM UTC-7, Dirk Heinrichs wrote:
>
> From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On 
> Behalf Of Dirk Heinrichs 
>
> > I'm currently seeing a strange problem where I get a Jgit exception 
> like: 
> > 
> > FATAL: Walk failure. 
> > org.eclipse.jgit.errors.MissingObjectException: Missing commit 
>  
> > 
> > in a job that's configured to use native Git. In fact, I'm also getting 
> the usual native Git output above the exception. 
> > But why is it using Jgit at all? 
>
> Could resolve it by temp. adding a "Wipe out repository & force clone". 
> However, the question remains: Why is it running Jgit at all? 
>
> Bye... 
>
> Dirk 
>
> -- 
> 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/d10250e8-4ee2-410f-9d51-5b21c92fadf4%40googlegroups.com
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_jenkinsci-2Dusers_d10250e8-2D4ee2-2D410f-2D9d51-2D5b21c92fadf4-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter=DwMFaQ=ZgVRmm3mf2P1-XDAyDsu4A=TsKycyisPP_6FVCeETRooIdY_8hdAsXoxwbvHso_TaI=FY-iG0RGKgIoqab_HHYa_loUvzejlGQumW_W_As5UC0=2HRIDV50HGIiufhD3Go786-hA9qgDmWN6DFBYUQw74o=>
> .
> For more options, visit https://groups.google.com/d/optout 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=DwMFaQ=ZgVRmm3mf2P1-XDAyDsu4A=TsKycyisPP_6FVCeETRooIdY_8hdAsXoxwbvHso_TaI=FY-iG0RGKgIoqab_HHYa_loUvzejlGQumW_W_As5UC0=9_XmUr1S5XQzCRQvYSlp5m9Me0hnbnjbQxQ8_HJe9No=>
> .
>

-- 
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/c9ff6d70-62d6-4bcc-93be-cdcfdf456a3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using Gradle in Pipeline

[Brian Ray]

We are, extensively.

I may be interpreting the issue wrong, but it seems like a more "native" 
pipeline API is not necessarily the blocker here.

Does this help at all?:

sh "gradle build --info --console=plain"

Those switches increase logging verbosity and eliminate the control 
characters that Jenkins console renders poorly.

More doc on Gradle's logging and other command line options is here 
.

On Thursday, April 12, 2018 at 11:02:43 PM UTC-7, Sverre Moe wrote:
>
> We are currently using Maven for building our applications. 
>
> Our Jenkins maven pipeline are using the withMaven step from Pipeline 
> Maven Integration.
>
> I have written gradle build scripts for our projects and begun to write 
> the Pipeline build script to build gradle.
>
> We could really use an Pipeline Gradle Integration plugin and an 
> withGradle step.
>
> In the absence of such a plugin I am left with
> tool name: 'gradle-4.6', type: 'gradle'
> sh "gradle build"
>
> I think I have to put some verbosity to gradle. The Jenkins console output 
> did not provide any insight while gradle was running the JUnit tests.
>
> :processResources
> :classes
> :jar
> :javadoc
> :javadocJar
> :sourcesJar
> :assemble
> :startMockServer
>
> :processTestResources
> :testClasses
> :test
>
> :stopMockServer
> :check
> :build
>
>
> After :test there was no output for about 2 minutes. Not until task test was 
> finished.
>
> Not knowing if the build has halted, a test taking to long, or some other 
> problem.
>
>
> Would be great to have something like the dynamic output from running gradle
>
> <=> 75% EXECUTING [15s]
>
> > :test > 100 tests completed
>
> > :test > Executing test com.company.api.ConnectionTest
>
>
>
> Running Gradle with --console=rich gives me this output, but it is a mess.
>
> :test [m [0K [7D [1B [2A [1m< [0;32;1m= [0;39;1m> 75% 
> EXECUTING [9s] [m [34D [1B [1m> :test [m [7D [1B [2A [1m< [0;32;1m= 
> [0;39;1m> 75% EXECUTING [9s] [m [34D [1B [1m> :test > 0 tests completed 
> [m [27D [1B [2A [1m< [0;32;1m= [0;39;1m> 75% EXECUTING [9s] [m 
> [34D [1B [1m> :test > 0 tests completed [m [27D [1B [2A [1m< 
> [0;32;1m= [0;39;1m> 75% EXECUTING [9s] [m [34D [1B [1m> :test > 
> 0 tests completed [m [27D [1B [2A [1m< [0;32;1m= [0;39;1m> 75% 
> EXECUTING [9s] [m [34D [1B [1m> :test > 0 tests completed [m [27D [1B [2A 
> [1m< [0;32;1m= [0;39;1m> 75% EXECUTING [9s] [m [34D [1B [1m> 
> :test > 0 tests 
> ...
> ...
> > 330 tests completed [m [29D [1B [1m> :test > Executing test 
> com.company.server.api.commands.Command1Test [m [0K [68D [1B [3A [1m< 
> [0;32;1m= [0;39;1m> 75% EXECUTING [1m 29s] [m [38D [1B [1m> 
> :test > 412 tests completed [m [29D [1B [1m> :test > Executing test 
> com.company.server.api.commands.Command2Test [m [76D [1B [3A [1m< 
> [0;32;1m= [0;39;1m> 75% EXECUTING [1m 29s] [m [38D [1B [1m> 
> :test > 507 tests completed [m [29D [1B [1m> :test > Executing test 
> com.company.server.api.commands.Command3Test [m [0K [68D [1B [3A [1m< 
> [0;32;1m= [0;39;1m> 75% EXECUTING [1m 29s] [m [38D [1B [1m> 
> :test > 661 tests completed [m [29D [1B> IDLE [0K [6D [1B [3A [1m< 
> [0;32;1m= [0;39;1m> 75% EXECUTING [1m 29s] [m [38D [1B [1m> 
> :test > 661 tests completed [m [29D [2B [3A [1m< [0;32;1m= 
> [0;39;1m> 75% EXECUTING [1m 29s] [m [38D [1B [1m> :test > 661 tests 
> completed [m [29D [2B [3A [1m< [0;32;1m= [0;39;1m> 75% 
> EXECUTING [1m 30s] [m [38D [1B [1m> :test > 661 tests completed [m [29D [2B 
> [3A [1m< [0;32;1m= [0;39;1m> 75% EXECUTING [1m 30s] [m [38D [1B 
> [1m> :test [m [0K [7D [2B [3A [1m< [0;32;1m= [0;39;1m> 75% 
> EXECUTING [1m 30s] [m [38D [1B [1m> :test [m [7D [2B [3A [0K
> [0K
> [32;1mBUILD SUCCESSFUL [0;39m in 1m 32s
> 11 actionable tasks: 11 executed
>
>
>
> Are anyone using gradle in their Jenkins pipeline?
>

-- 
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/78434a79-2816-499e-8b5c-f4215e55a7be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting Jgit exception in a Job that uses native Git

[Brian Ray]

Navigate to *Manage Jenkins* > *Global Tool Configuration* > *Git* > *Git 
Installations*.

If the only installation configured there is *JGit *or *JGit with Apache 
HTTP client*, that is the answer. The *Git *installation will probably be 
what you are looking for.

On Friday, March 23, 2018 at 4:21:32 AM UTC-7, Dirk Heinrichs wrote:
>
> From: jenkins...@googlegroups.com  [mailto:
> jenkins...@googlegroups.com ] On Behalf Of Dirk Heinrichs 
>
> > I'm currently seeing a strange problem where I get a Jgit exception 
> like: 
> > 
> > FATAL: Walk failure. 
> > org.eclipse.jgit.errors.MissingObjectException: Missing commit 
>  
> > 
> > in a job that's configured to use native Git. In fact, I'm also getting 
> the usual native Git output above the exception. 
> > But why is it using Jgit at all? 
>
> Could resolve it by temp. adding a "Wipe out repository & force clone". 
> However, the question remains: Why is it running Jgit at all? 
>
> Bye... 
>
> Dirk 
>
>

-- 
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/d10250e8-4ee2-410f-9d51-5b21c92fadf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Static Analysis Collector Plugin and Pipelines

[Brian Ray]

My wording at the end should probably be "not yet been ehnanced with their 
own pripline-friendly symbolic step API."

Brian

On Monday, May 7, 2018 at 2:33:43 PM UTC-7, Brian Ray wrote:
>
> Documentation for the *step* step and indeed its usage with the 
> *AnalysisPublisher* step as well is here 
> <https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-step-code-general-build-step>.
>  
> The former is a bridge in pipeline to plugin-provided steps that have not 
> yet been enhanced with their own pipeline-friendly symbolic steps.
>
> Brian
>
> On Thursday, February 15, 2018 at 5:55:16 AM UTC-8, Ingmar Wirths wrote:
>>
>> I'm still looking for an explanation for below syntax, but haven't 
>> received an answer yet. Maybe I shouldn't have changed the subject; I 
>> now reverted the subject back to the original one. 
>>
>> On Mo, 2018-02-12 at 15:45 +0100, Ingmar Wirths wrote: 
>> > This syntax is new to me: 
>> > 
>> > step([$class: 'AnalysisPublisher‘]) 
>> > 
>> > I've been searching in the Jenkins documentation, but I couldn't find 
>> > an explanation for it. It looks like it enables me to call an 
>> > arbitrary 
>> > Java method. Is this correct? 
>> > 
>> > However, there are still questions: 
>> > 1. How do I specify the method to be called? 
>> > 2. How do I pass method parameters? 
>> > 3. What are the preconditions / limitations of this syntax? 
>> > 
>> > If there is documentation on this syntax and I've just missed it I 
>> > would appreciate a link. 
>> > 
>> > Cheers~ 
>> > 
>> > On Mi, 2018-02-07 at 23:30 +0100, Ullrich Hafner wrote: 
>> > > 
>> > > 
>> > > 
>> > > > 
>> > > > Am 07.02.2018 um 16:12 schrieb Ingmar Wirths <iwi...@bry-it.com> 
>> > > > : 
>> > > > 
>> > > > Hello, 
>> > > > 
>> > > > I would like to use the Static Analysis Collector Plugin with my 
>> > > > Jenkins pipeline project. 
>> > > > 
>> > > > Can I do that? If so, how? 
>> > > > 
>> > > yes. 
>> > > 
>> > > step([$class: 'AnalysisPublisher‘]) 
>> > > 
>> > > You can specify all options of https://github.com/jenkinsci/analysi 
>> > > s- 
>> > > collector- 
>> > > plugin/blob/master/src/main/java/hudson/plugins/analysis/collector/ 
>> > > An 
>> > > alysisPublisher.java 
>> > > 
>> > > I have no idea why this step is not shown in the Snippet Generator… 
>> > > 
>> > > > 
>> > > > The only hint I found that the Static Analysis Collector Plugin 
>> > > > might 
>> > > > support pipelines is on the release notes for 1.49: 
>> > > > 
>> > > > Added trend graph support for pipelines (JENKINS-31202, thanks to 
>> > > > Benjamin Fuchs for the help!) 
>> > > > 
>> > > > That looks promising; however, I was unable to find documentation 
>> > > > on 
>> > > > the pipeline steps regarding the Static Analysis Collector 
>> > > > Plugin. 
>> > > > 
>> > > > So, how should I proceed? 
>> > > > 
>> > > > Cheers~ 
>> > > > 
>> > > > --  
>> > > > 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.co 
>> > > > m/ 
>> > > > d/msgid/jenkinsci-users/1518016365.9915.9.camel%40bry-it.com. 
>> > > > 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-use...@googlegroups.com. 
>> > > To view this discussion on the web visit https://groups.google.com/ 
>> > > d/ 
>> > > msgid/jenkinsci-users/ECF4A3AF-48FF-4B4A-9E52- 
>> > > BBB851C99A18%40gmail.com. 
>> > > 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/9335f60f-ef3e-48e1-85c9-a9910dd26859%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Static Analysis Collector Plugin and Pipelines

[Brian Ray]

My wording at the end should probably be "not yet been ehnanced with their 
own pipeline-friendly symbolic step API."

Brian

On Monday, May 7, 2018 at 2:33:43 PM UTC-7, Brian Ray wrote:
>
> Documentation for the *step* step and indeed its usage with the 
> *AnalysisPublisher* step as well is here 
> <https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-step-code-general-build-step>.
>  
> The former is a bridge in pipeline to plugin-provided steps that have not 
> yet been enhanced with their own pipeline-friendly symbolic steps.
>
> Brian
>
> On Thursday, February 15, 2018 at 5:55:16 AM UTC-8, Ingmar Wirths wrote:
>>
>> I'm still looking for an explanation for below syntax, but haven't 
>> received an answer yet. Maybe I shouldn't have changed the subject; I 
>> now reverted the subject back to the original one. 
>>
>> On Mo, 2018-02-12 at 15:45 +0100, Ingmar Wirths wrote: 
>> > This syntax is new to me: 
>> > 
>> > step([$class: 'AnalysisPublisher‘]) 
>> > 
>> > I've been searching in the Jenkins documentation, but I couldn't find 
>> > an explanation for it. It looks like it enables me to call an 
>> > arbitrary 
>> > Java method. Is this correct? 
>> > 
>> > However, there are still questions: 
>> > 1. How do I specify the method to be called? 
>> > 2. How do I pass method parameters? 
>> > 3. What are the preconditions / limitations of this syntax? 
>> > 
>> > If there is documentation on this syntax and I've just missed it I 
>> > would appreciate a link. 
>> > 
>> > Cheers~ 
>> > 
>> > On Mi, 2018-02-07 at 23:30 +0100, Ullrich Hafner wrote: 
>> > > 
>> > > 
>> > > 
>> > > > 
>> > > > Am 07.02.2018 um 16:12 schrieb Ingmar Wirths <iwi...@bry-it.com> 
>> > > > : 
>> > > > 
>> > > > Hello, 
>> > > > 
>> > > > I would like to use the Static Analysis Collector Plugin with my 
>> > > > Jenkins pipeline project. 
>> > > > 
>> > > > Can I do that? If so, how? 
>> > > > 
>> > > yes. 
>> > > 
>> > > step([$class: 'AnalysisPublisher‘]) 
>> > > 
>> > > You can specify all options of https://github.com/jenkinsci/analysi 
>> > > s- 
>> > > collector- 
>> > > plugin/blob/master/src/main/java/hudson/plugins/analysis/collector/ 
>> > > An 
>> > > alysisPublisher.java 
>> > > 
>> > > I have no idea why this step is not shown in the Snippet Generator… 
>> > > 
>> > > > 
>> > > > The only hint I found that the Static Analysis Collector Plugin 
>> > > > might 
>> > > > support pipelines is on the release notes for 1.49: 
>> > > > 
>> > > > Added trend graph support for pipelines (JENKINS-31202, thanks to 
>> > > > Benjamin Fuchs for the help!) 
>> > > > 
>> > > > That looks promising; however, I was unable to find documentation 
>> > > > on 
>> > > > the pipeline steps regarding the Static Analysis Collector 
>> > > > Plugin. 
>> > > > 
>> > > > So, how should I proceed? 
>> > > > 
>> > > > Cheers~ 
>> > > > 
>> > > > --  
>> > > > 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.co 
>> > > > m/ 
>> > > > d/msgid/jenkinsci-users/1518016365.9915.9.camel%40bry-it.com. 
>> > > > 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-use...@googlegroups.com. 
>> > > To view this discussion on the web visit https://groups.google.com/ 
>> > > d/ 
>> > > msgid/jenkinsci-users/ECF4A3AF-48FF-4B4A-9E52- 
>> > > BBB851C99A18%40gmail.com. 
>> > > 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/40930da3-b318-4485-8151-51bad0f6880a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Static Analysis Collector Plugin and Pipelines

[Brian Ray]

Documentation for the *step* step and indeed its usage with the 
*AnalysisPublisher* step as well is here 
.
 
The former is a bridge in pipeline to plugin-provided steps that have not 
yet been enhanced with their own pipeline-friendly symbolic steps.

Brian

On Thursday, February 15, 2018 at 5:55:16 AM UTC-8, Ingmar Wirths wrote:
>
> I'm still looking for an explanation for below syntax, but haven't 
> received an answer yet. Maybe I shouldn't have changed the subject; I 
> now reverted the subject back to the original one. 
>
> On Mo, 2018-02-12 at 15:45 +0100, Ingmar Wirths wrote: 
> > This syntax is new to me: 
> > 
> > step([$class: 'AnalysisPublisher‘]) 
> > 
> > I've been searching in the Jenkins documentation, but I couldn't find 
> > an explanation for it. It looks like it enables me to call an 
> > arbitrary 
> > Java method. Is this correct? 
> > 
> > However, there are still questions: 
> > 1. How do I specify the method to be called? 
> > 2. How do I pass method parameters? 
> > 3. What are the preconditions / limitations of this syntax? 
> > 
> > If there is documentation on this syntax and I've just missed it I 
> > would appreciate a link. 
> > 
> > Cheers~ 
> > 
> > On Mi, 2018-02-07 at 23:30 +0100, Ullrich Hafner wrote: 
> > > 
> > > 
> > > 
> > > > 
> > > > Am 07.02.2018 um 16:12 schrieb Ingmar Wirths  > 
> > > > : 
> > > > 
> > > > Hello, 
> > > > 
> > > > I would like to use the Static Analysis Collector Plugin with my 
> > > > Jenkins pipeline project. 
> > > > 
> > > > Can I do that? If so, how? 
> > > > 
> > > yes. 
> > > 
> > > step([$class: 'AnalysisPublisher‘]) 
> > > 
> > > You can specify all options of https://github.com/jenkinsci/analysi 
> > > s- 
> > > collector- 
> > > plugin/blob/master/src/main/java/hudson/plugins/analysis/collector/ 
> > > An 
> > > alysisPublisher.java 
> > > 
> > > I have no idea why this step is not shown in the Snippet Generator… 
> > > 
> > > > 
> > > > The only hint I found that the Static Analysis Collector Plugin 
> > > > might 
> > > > support pipelines is on the release notes for 1.49: 
> > > > 
> > > > Added trend graph support for pipelines (JENKINS-31202, thanks to 
> > > > Benjamin Fuchs for the help!) 
> > > > 
> > > > That looks promising; however, I was unable to find documentation 
> > > > on 
> > > > the pipeline steps regarding the Static Analysis Collector 
> > > > Plugin. 
> > > > 
> > > > So, how should I proceed? 
> > > > 
> > > > Cheers~ 
> > > > 
> > > > --  
> > > > 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.co 
> > > > m/ 
> > > > d/msgid/jenkinsci-users/1518016365.9915.9.camel%40bry-it.com. 
> > > > 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-use...@googlegroups.com . 
> > > To view this discussion on the web visit https://groups.google.com/ 
> > > d/ 
> > > msgid/jenkinsci-users/ECF4A3AF-48FF-4B4A-9E52- 
> > > BBB851C99A18%40gmail.com. 
> > > 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/36232e5b-6e20-45e9-a674-500e5cd46ed9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Separating JUnit test reporting for files in different folders

[Brian Ray]

Per JENKINS-27395 , it 
seems so. I'm interested in the same functionality for XUnit 
(JENKIINS-45826).

Brian

On Wednesday, January 31, 2018 at 3:04:06 AM UTC-8, James Telfer wrote:
>
> Hi,
>
> I suspect the answer to this is no, at least from what I've seen on the 
> plugin page and the available options within the Jenkins UI, but worth 
> asking.
>
> I've recently migrated a build which used Multijob to Pipline.  The 
> Multijob used a number of different build & test jobs, each of which would 
> report test results separately.  These jobs aligned to different levels of 
> testing (unit/component/system), which were therefore reported separately.  
> Under pipeline this doesn't happen, I get all of the results reported 
> together under the '(root)' package in the test results view.
>
> Is there any way to get the reporter to report the results from each stage 
> separately?
>
> Thanks,
> James Telfer
>

-- 
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/c97914fd-b46d-4842-b092-0a927612ee86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "Jenkins is going to shut down" ad infinitum

[Brian Ray]

We ran into the same problem under what sounds like the same circumstances 
a few years back. We initially configured thinBackup with the *Wait 
until...* switch turned on and had no issues for a very long time.

And then we wound up in the trap you describe. I dug around and realized 
certain of our long-running nightly jobs were running longer and longer, 
and more job were introduced, delaying thinBackup's opportunity to seize a 
quiet period. By the time late morning rolled around it was in the shutdown 
preparation mode, so I'd manually clear it, and then a delayed build would 
fire, and then back to shutdown prep mode, etc.

So while it's possible for the thinBackup config to remain the same but 
build mix + timing to cause this problem.

On Monday, November 27, 2017 at 9:22:37 AM UTC-8, Steve K wrote:
>
>
> Thank you Victor Martinez and matthew...@diamond.ac.uk for your great 
> ideas.  I apologize for my late response.  We were on a Thanksgiving 
> holiday.
>
> We managed to work past the problem. No Groovy scripts were to blame.
> As a guess, we de-selected "Wait until Jenkins/Hudson is idle to perform a 
> backup" in our thinBackup settings.
> That fixed the problem.
> As I originally noted, however, it is very odd that we just experienced 
> this issue.  The configuration for thinBackup had not been changed in 
> several months.
>
>

-- 
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/e736bc8f-23e7-4b55-9b91-9c4f97344eb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Defining *project level* environemnt variables

[Brian Ray]

Forgot to write: We mitigate the hack by wrapping it up as a global library 
custom step.

On Tuesday, December 5, 2017 at 1:57:46 PM UTC-8, Brian Ray wrote:
>
> We use the Config File Provider plugin 
> <https://plugins.jenkins.io/config-file-provider> and the Pipeline 
> Utilities Steps plugin <https://plugins.jenkins.io/pipeline-utility-steps> 
> in conjunction with folders to get around the JENKINS-42906 gap, in a 
> Scripted Pipeline context.
>
> This is actually nicer IMHO than the hidden env variables functionality, 
> because you can use various flavors of configuration files, use an editor 
> that understands your flavor(s) of choice, and then paste back into the UI.
>
> In our case we're just using simple Java properties files something like 
> the following.
>
>   def props
>   node() {
> configFileProvider( [ configFile( fileId: 'your-folder-cfg-file-id', 
> variable: 'WHATEVER', replaceTokens: true ) ] ) {
>   props = readProperties( file: WHATEVER )
> }
>   }
>   //now go do stuff with the props Map, even massaging for consumption by 
> withEnv() ...
>
> The ony downside is, I suppose, is the hacky nature of having the 
> properties written down to the agent's workspace just to read them right 
> back again and discard the file.
>
> Brian
>
> On Wednesday, October 25, 2017 at 11:39:09 AM UTC-7, Sébastien Hinderer 
> wrote:
>>
>> Thanks a lot for your response, Stephen. 
>> Not sure I'm brave enough to try to write something myself. 
>> Just too bad it does not already exist but I guess we'll just do without 
>> since it'd be a nice addition but not really mandatory. 
>>
>> Best wishes, 
>>
>> Sébastien. 
>>
>

-- 
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/688fd93b-db7c-4f54-a4f0-90d9a24b781d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Defining *project level* environemnt variables

[Brian Ray]

We use the Config File Provider plugin 
 and the Pipeline 
Utilities Steps plugin  
in conjunction with folders to get around the JENKINS-42906 gap, in a 
Scripted Pipeline context.

This is actually nicer IMHO than the hidden env variables functionality, 
because you can use various flavors of configuration files, use an editor 
that understands your flavor(s) of choice, and then paste back into the UI.

In our case we're just using simple Java properties files something like 
the following.

  def props
  node() {
configFileProvider( [ configFile( fileId: 'your-folder-cfg-file-id', 
variable: 'WHATEVER', replaceTokens: true ) ] ) {
  props = readProperties( file: WHATEVER )
}
  }
  //now go do stuff with the props Map, even massaging for consumption by 
withEnv() ...

The ony downside is, I suppose, is the hacky nature of having the 
properties written down to the agent's workspace just to read them right 
back again and discard the file.

Brian

On Wednesday, October 25, 2017 at 11:39:09 AM UTC-7, Sébastien Hinderer 
wrote:
>
> Thanks a lot for your response, Stephen. 
> Not sure I'm brave enough to try to write something myself. 
> Just too bad it does not already exist but I guess we'll just do without 
> since it'd be a nice addition but not really mandatory. 
>
> Best wishes, 
>
> Sébastien. 
>

-- 
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/f82c51af-34dc-4db8-b2bb-142177b10fbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins nested view vs nested folder structure ?

[Brian Ray]

We use both in our primary Jenkins environment, though folders are the 
primary organizing mechanism.

The views are treated more like convenient "favorites" lists of jobs.

Brian

On Sunday, January 8, 2017 at 5:49:36 PM UTC-8, Brian Ray wrote:
>
> To name a few advantages, you can associate credential stores and Pipeline 
> shared libraries with folders so that they are visible only to the jobs 
> they contain. Through the Role Strategy plugin, you can also assign various 
> privileges--and not simply read privileges--to jobs inside different 
> folders.
>
> I don't think you can do any of those things views.
>
> Note: these advantages have nothing to do with how deeply the folders are 
> nested.
>
> Brian
>
> On Thursday, December 29, 2016 at 9:29:44 AM UTC-8, user_dev wrote:
>>
>> I am trying to understand the use case of having a nested folder 
>> structure in Jenkins to manage the different set of jobs. Previously I have 
>> been using nested view plugin to achieve that. But with folder structure in 
>> place what advantage it brings over nested view and subviews. Please 
>> explain.
>>
>

-- 
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/530827ec-b0e9-4ede-bcc3-81af3b8ee488%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins nested view vs nested folder structure ?

[Brian Ray]

To name a few advantages, you can associate credential stores and Pipeline 
shared libraries with folders so that they are visible only to the jobs 
they contain. Through the Role Strategy plugin, you can also assign various 
privileges--and not simply read privileges--to jobs inside different 
folders.

I don't think you can do any of those things views.

Note: these advantages have nothing to do with how deeply the folders are 
nested.

Brian

On Thursday, December 29, 2016 at 9:29:44 AM UTC-8, user_dev wrote:
>
> I am trying to understand the use case of having a nested folder structure 
> in Jenkins to manage the different set of jobs. Previously I have been 
> using nested view plugin to achieve that. But with folder structure in 
> place what advantage it brings over nested view and subviews. Please 
> explain.
>

-- 
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/ad8b3fab-d8ab-449a-9396-6c2cd4650663%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins nested view vs nested folder structure ?

[Brian Ray]

To name a few advantages, you can associate credential stores and Pipeline 
shared libraries with folders so that they are visible . Through the Role 
Strategy plugin, you can also assign various privileges--and not simply 
read privileges--to jobs inside different folders.

I don't think you can do any of those things views.

Note: these advantages have nothing to do with how deeply the folders are 
nested.

Brian

On Thursday, December 29, 2016 at 9:29:44 AM UTC-8, user_dev wrote:
>
> I am trying to understand the use case of having a nested folder structure 
> in Jenkins to manage the different set of jobs. Previously I have been 
> using nested view plugin to achieve that. But with folder structure in 
> place what advantage it brings over nested view and subviews. Please 
> explain.
>

-- 
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/64d049fb-17d5-499f-bfea-57f6667bbbc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Version on CentOS 7.2

[Brian Ray]

FWIW we have a few agents running on CentOS 7.1/OpenJDK 1.8. No issues.

On Wednesday, November 16, 2016 at 7:44:06 PM UTC-8, Daniel Beck wrote:
>
>
> > On 16.11.2016, at 21:36, Aaron K  wrote: 
> > 
> > Is OpenJDK 1.8 supported on CentOS 7.2?   
> > 
> > We're installing with sudo yum install -y java-1.8.0-openjdk 
> > 
> > Is there a Java compatibility list somewhere for Jenkins that I can 
> reference? 
>
> I don't think we have specific requirements, but OpenJDK 8 on RHEL is 
> expected to work. 
>
> CloudBees (my employer) offers commercial support for Jenkins and is more 
> explicit about what's supported: 
>
> https://support.cloudbees.com/hc/en-us/articles/203601234-CloudBees-Jenkins-Platform-Supported-Java-Versions
>  
>
> If that says it's supported for CloudBees' Jenkins-based products, you can 
> expect it to work with Jenkins. 
>
>

-- 
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/84921268-0c9d-43cf-afa9-595e49954bfb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: concurrency parameter no longer accepted for stage block?

[Brian Ray]

Yes, there's a more sophisticated way of doing this now. Here's a good blog 
post  on the 
technique.

On Monday, October 17, 2016 at 10:44:49 AM UTC-7, Kyle Flavin wrote:
>
> I posted this in the wrong place previously - hope this is correct.
>
> Does the concurrency parameter no longer apply to the stage block?  This 
> post is in reference to: 
> https://issues.jenkins-ci.org/browse/JENKINS-26107
>
> I have some legacy code, and I'm converting "stage" to use the new block 
> format. We have a lot of stuff that looks like this: 
>
>
> stage name: 's1: do something', concurrency: 1
>  ...
>
> stage name: 's2: do something else', concurrency: 1
>  ...
>
>
>
> I'm not entirely sure what "concurrency" is doing, or if it's even 
> necessary to preserve in this case.  I can't find much reference to the new 
> form in the docs.  Is it safe to just ignore the parameter?  Is it handled 
> in some other way now?:
>
>
> stage("s1: do something") {
> ...
>
> }
>

-- 
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/5b949ba8-f6ac-45ba-bc44-1643331eb3fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Restricting job list permission using Role-Based Strategy

[Brian Ray]

The wiki page for the plugin 
 
describes how to restrict user access to certain jobs (projects).

Note the warning about global roles superseding project roles 

.

On Thursday, October 13, 2016 at 11:59:15 PM UTC-7, Maneesh M P wrote:
>
> Hello,
>
> We are using Role Based Strategy plugin for our authorization. The problem 
> I am currently facing is, I am unable to restrict user to view jobs only 
> which he is authorized to.
> With my current configuration a logged in user can see all the jobs, 
> though he wont have any other permission to execute or configure etc.
>
> Is there a way I can control the job listing also with Role Based strategy 
> plugin ?
>
> Thanks,
> Maneesh
>
>

-- 
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/e6886cf9-3e61-431f-965b-b4b3fdbaf23d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline Groovy Madness

[Brian Ray]

Keep an eye on JENKINS-35390 
.

Though the other day I optimistically tried to use Groovy's AST transform 
@Immutable 
 
on a class ... should've known that would not play nicely with the CPS 
transforms.

On Friday, October 14, 2016 at 8:33:49 AM UTC-7, Jonathan Hodgson wrote:
>
>
>
> On Friday, October 14, 2016 at 1:47:24 PM UTC+1, Daniel Beck wrote:
>>
>>
>> > On 14.10.2016, at 13:25, Jonathan Hodgson  wrote: 
>> > 
>> > All I've done is move that one line, and for the record at the moment 
>> it's being called without OSX being active, so nothing inside that first if 
>> statement is being executed (though it shouldn't cause any problems even if 
>> its was) 
>> > 
>> > I'm confused, and frustrated. Any help greatly appreciated. 
>>
>> The last statement in a Groovy method is the implicit return value. 
>> `find` returns a LinkedHashMap$Entry, it gets returned from the method 
>> call, and it breaks due to CPS serialization. 
>>
>> Thanks Daniel, I'm still finding my feet with Groovy, throw in the CPS 
> issues plus other pipeline job problems (e.g. the lack of working file 
> parameters) and I find myself going round and round until I don't know 
> which way is up, down or sideways.
>
> Changing things to
>
> @NonCPS def isPlatformActive(platform, active_builds)
> {
> found = (null != active_builds[platform].find { it.value == true } )
> found
> }
>
> Seems to have fixed this issue
>
>
>> Regarding the regression, likely due to 
>> https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Groovy+Plugin#PipelineGroovyPlugin-2.14%28Sep07%2C2016%29
>>  
>>
>>
> Thanks again.
>
> It's the lack of consistency which is driving me nuts, things work in one 
> place, but not another, or they work with one version, but not the next. It 
> makes debugging so hard. 
>
> And for the love of God could somebody please implement some useful error 
> messages!?
>
> Things should either work, or not work with a suitable error message.
>
> I don't know how difficult it would be, but a lint style checker that 
> would pick up forbidden constructs in CPS functions would be nice too... 
> but there I'm getting into dreamland I fear.
>

-- 
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/02e75241-3f24-4e97-b446-aa145870995a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: irreconcilable unclassified staticMethod exception in sandbox mode

[Brian Ray]

More info: running LTS 2.7.4 core with the following relevant Pipeline and 
Script Security plugins:

Pipeline: Build Steppipeline-build-step2.3
Pipeline Graph Analysis Pluginpipeline-graph-analysis1.1
Pipeline: Input Steppipeline-input-step2.1
Pipeline: Milestone Steppipeline-milestone-step1.0
Pipeline: REST API Pluginpipeline-rest-api2.0
Pipeline: Stage Steppipeline-stage-step2.2
Pipeline: Stage View Pluginpipeline-stage-view2.0
Script Security Pluginscript-security1.23
Pipelineworkflow-aggregator2.4
Pipeline: APIworkflow-api2.4
Pipeline: Basic Stepsworkflow-basic-steps2.2
Pipeline: Groovyworkflow-cps2.18
Pipeline: Shared Groovy Librariesworkflow-cps-global-lib2.3
Pipeline: Nodes and Processesworkflow-durable-task-step2.5
Pipeline: Jobworkflow-job2.7
Pipeline: Multibranchworkflow-multibranch2.9
Pipeline: SCM Stepworkflow-scm-step2.2
Pipeline: Step APIworkflow-step-api2.4
Pipeline: Supporting APIsworkflow-support2.6


On Tuesday, October 4, 2016 at 10:05:38 AM UTC-7, Brian Ray wrote:
>
> In trying to make a temporary stopgap for JIRA-26100 
> <https://issues.jenkins-ci.org/browse/JENKINS-26100>, I came up with this 
> toy code that runs fine in the (unsandboxed, natch) Script Console:
>
> import org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory
> import org.tmatesoft.svn.core.SVNURL
>
> DAVRepositoryFactory.setup()
> url = SVNURL.parseURIEncoded(
>   'https://foosvnserver/svn/awesome_proj/trunk'
> )
> //FIXME: can't get this past script-security even when whitelisted per the 
> //   stack trace,
> //
> //   staticMethod 
> org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory create 
> org.tmatesoft.svn.core.SVNURL
> repo = DAVRepositoryFactory.create(url)
> repo.properties
> println "Latest rev for trunk Java: $repo.latestRevision"
>
>
> In trying it as a sandboxed, non-multibranch Pipeline script I had to 
> whitelist the SVNKit static methods. The first two that popped up went 
> fine, the approval effectively whitelisted them:
>
> staticMethod org.tmatesoft.svn.core.SVNURL parseURIEncoded java.lang.
> String
> staticMethod org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory 
> setup
>
>
> But the last one is apparently intractible. I had to manually add this one 
> to scriptApproval.xml because the scriptApproval page wouldn't display it 
> for approval.
>
> staticMethod org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory 
> create org.tmatesoft.svn.core.SVNURL
>
>
> Even after bouncing the master the sandboxed script still throws the 
> following stack trace. It feels like I'm missing something elementary. Any 
> ideas on why that method is not effectively being whitelisted? (Note: the 
> stack trace references line 12 of the script but I chopped some comment 
> lines from the above script excerpt. It is flagging the 
> *DAVRepositoryFactory.create(url*) call.
>
> org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: 
> unclassified staticMethod org.tmatesoft.svn.core.internal.io.dav.
> DAVRepositoryFactory create org.tmatesoft.svn.core.SVNURL
> at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.
> SandboxInterceptor.onStaticCall(SandboxInterceptor.java:138)
> at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:180)
> at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.
> java:177)
> at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:91
> )
> at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(
> SandboxInvoker.java:16)
> at WorkflowScript.run(WorkflowScript:12)
> at ___cps.transform___(Native Method)
> at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(
> ContinuationGroup.java:48)
> at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.
> dispatchOrArg(FunctionCallBlock.java:109)
> at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.
> fixArg(FunctionCallBlock.java:82)
> at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.
> receive(ContinuationPtr.java:72)
> at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get
> (PropertyishBlock.java:76)
> at com.cloudbee

Pipeline: irreconcilable unclassified staticMethod exception in sandbox mode

[Brian Ray]

In trying to make a temporary stopgap for JIRA-26100 
, I came up with this 
toy code that runs fine in the (unsandboxed, natch) Script Console:

import org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory
import org.tmatesoft.svn.core.SVNURL

DAVRepositoryFactory.setup()
url = SVNURL.parseURIEncoded(
  'https://foosvnserver/svn/awesome_proj/trunk'
)
//FIXME: can't get this past script-security even when whitelisted per the 
//   stack trace,
//
//   staticMethod 
org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory create 
org.tmatesoft.svn.core.SVNURL
repo = DAVRepositoryFactory.create(url)
repo.properties
println "Latest rev for trunk Java: $repo.latestRevision"


In trying it as a sandboxed, non-multibranch Pipeline script I had to 
whitelist the SVNKit static methods. The first two that popped up went 
fine, the approval effectively whitelisted them:

staticMethod org.tmatesoft.svn.core.SVNURL parseURIEncoded java.lang.String
staticMethod org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory 
setup


But the last one is apparently intractible. I had to manually add this one 
to scriptApproval.xml because the scriptApproval page wouldn't display it 
for approval.

staticMethod org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory 
create org.tmatesoft.svn.core.SVNURL


Even after bouncing the master the sandboxed script still throws the 
following stack trace. It feels like I'm missing something elementary. Any 
ideas on why that method is not effectively being whitelisted? (Note: the 
stack trace references line 12 of the script but I chopped some comment 
lines from the above script excerpt. It is flagging the 
*DAVRepositoryFactory.create(url*) call.

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: 
unclassified staticMethod org.tmatesoft.svn.core.internal.io.dav.
DAVRepositoryFactory create org.tmatesoft.svn.core.SVNURL
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.
SandboxInterceptor.onStaticCall(SandboxInterceptor.java:138)
at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:180)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.
java:177)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:91)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(
SandboxInvoker.java:16)
at WorkflowScript.run(WorkflowScript:12)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(
ContinuationGroup.java:48)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.
dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.
fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.
receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(
PropertyishBlock.java:76)
at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.
java:30)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.
fixName(PropertyishBlock.java:66)
at sun.reflect.GeneratedMethodAccessor344.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.
receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:
21)
at com.cloudbees.groovy.cps.Next.step(Next.java:58)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(
SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(
SandboxContinuable.java:33)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(
SandboxContinuable.java:30)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.
runInSandbox(GroovySandbox.java:108)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(
SandboxContinuable.java:30)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.
java:163)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.
java:324)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(
CpsThreadGroup.java:78)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(
CpsThreadGroup.java:236)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(
CpsThreadGroup.java:224)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(

Re: Pipeline external global library in SVN - errors

[Brian Ray]

I entered low priority JIRA-38517 
<https://issues.jenkins-ci.org/browse/JENKINS-38517> for the above issue.

On Friday, September 16, 2016 at 5:58:38 PM UTC-7, Brian Ray wrote:
>
>
> <https://lh3.googleusercontent.com/-SMw50qq6uoY/V9yTzIFPqOI/ARI/e2vw4-JHWoMzKId6wdV5Jrkc4PR8-TxLACLcB/s1600/firefox_2016-09-16_17-47-51.png>
>
>
> These discrepencies nudged me toward the solution. Until my latest 
> attempt, I only observed the checkout in that shared location (1). There 
> was no checked out library code in the build directories (2). But I now 
> have a clean test build and build library subdirectories as you detailed, 
> in addition to the shared location. The difference in configuration is the 
> *Local 
> module directory* value above, where the dot strips the parent project 
> directory.
>
> The method source in the plugin's Github repo makes much more sense now.
>
> I wonder if my previous attempts are edge cases that warrant a JIRA. The 
> shared library resolver should not, it seems, get confused if the 
> project/module directory is retained on checkout. At the least the 
> README.md 
> <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/README.md>
>  
> could contain some more guidance on configuration in this case.
>
> Thanks again!
>
> On Friday, September 16, 2016 at 5:19:54 PM UTC-7, Michael Lasevich wrote:
>>
>> You are probably farther along than me as I have not even looked at the 
>> code, but what I am observing on my end is this:
>>
>> There is a some sort of a shared location, in my case "workspace@libs/" 
>> directory, which seems to house the repo (note that name of the library is 
>> not there), and then inside individual builds there is a lib// 
>> directory which contains the snapshot in time of the library that is 
>> actually used for this build. I am using git, so there is a git repo in the 
>> first place, but only the files in the build - but I suspect there is a 
>> similar thing for svn
>>
>> A few things that I see here that are different in your case:
>>
>> 1 - Your workspace is not named "workspace@libs" but is instead named 
>> "x-pipeline-1@libs" - not sure if this is a per-build directory, or a 
>> shared repo dir
>> 2 - If #1 is your shared directory,  you have an extra subdirectory in 
>> there.
>>
>> Try searching for "cmd.groovy" under your job directory and see where all 
>> the copies are. See where there is a .svn dir vs where there is just a copy 
>> and make sure that it is in the right place.
>>
>> -M
>>
>>
>> On Friday, September 16, 2016 at 5:03:13 PM UTC-7, Brian Ray wrote:
>>>
>>> All good tips. I've been blowing away the local copy between attempts 
>>> and currently have this structure (note: I changed the configured libname 
>>> from *helpers *to *pipelineGlobalHelpers *in the latest attempt, and 
>>> this is checking out on my local troubleshooter master right now--this is 
>>> even before the first *stage *or *node *blocks):
>>>
>>> c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\
>>> pipelineGlobalHelpers>dir
>>>  Volume in drive C has no label.
>>>  Volume Serial Number is 4456-EE0F
>>>
>>>  Directory of c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\
>>> pipelineGlobalHelpers
>>>
>>> 2016-09-16  16:18  .
>>> 2016-09-16  16:18  ..
>>> 2016-09-16  16:18  resources
>>> 2016-09-16  16:18  src
>>> 2016-09-16  16:18  vars
>>>0 File(s)  0 bytes
>>>5 Dir(s)  249,994,575,872 bytes free
>>>
>>>
>>> This 
>>> <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/1b70381dbda34e6fd9acb15b4c206e9aec75c965/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryAdder.java#L147-L183>
>>>  
>>> is likely the method that's complaining; see the *throw *at the end.
>>>
>>> The thing that I am puzzling at is the construction of the directory 
>>> path:
>>>
>>> FilePath libDir = new FilePath(execution.getOwner().getRootDir()).child(
>>> "libs/" + name);
>>>
>>> That to me suggests it yields 
>>> c:/Jenkins/workspace/Dev-Snippets/x-pipeline-1/libs/pipelineGlobalHelpers, 
>>> instead of .../x-pipeline-1@libs/pipelineGlobalHelpers, but maybe I am 
>>> misunderstanding *FilePath#child* or *#getRootDir*.
>>>
>>> There are still a few more e

Re: Pipeline external global library in SVN - errors

[Brian Ray]

<https://lh3.googleusercontent.com/-SMw50qq6uoY/V9yTzIFPqOI/ARI/e2vw4-JHWoMzKId6wdV5Jrkc4PR8-TxLACLcB/s1600/firefox_2016-09-16_17-47-51.png>


These discrepencies nudged me toward the solution. Until my latest attempt, 
I only observed the checkout in that shared location (1). There was no 
checked out library code in the build directories (2). But I now have a 
clean test build and build library subdirectories as you detailed, in 
addition to the shared location. The difference in configuration is the *Local 
module directory* value above, where the dot strips the parent project 
directory.

The method source in the plugin's Github repo makes much more sense now.

I wonder if my previous attempts are edge cases that warrant a JIRA. The 
shared library resolver should not, it seems, get confused if the 
project/module directory is retained on checkout. At the least the README.md 
<https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/README.md>
 
could contain some more guidance on configuration in this case.

Thanks again!

On Friday, September 16, 2016 at 5:19:54 PM UTC-7, Michael Lasevich wrote:
>
> You are probably farther along than me as I have not even looked at the 
> code, but what I am observing on my end is this:
>
> There is a some sort of a shared location, in my case "workspace@libs/" 
> directory, which seems to house the repo (note that name of the library is 
> not there), and then inside individual builds there is a lib// 
> directory which contains the snapshot in time of the library that is 
> actually used for this build. I am using git, so there is a git repo in the 
> first place, but only the files in the build - but I suspect there is a 
> similar thing for svn
>
> A few things that I see here that are different in your case:
>
> 1 - Your workspace is not named "workspace@libs" but is instead named 
> "x-pipeline-1@libs" - not sure if this is a per-build directory, or a 
> shared repo dir
> 2 - If #1 is your shared directory,  you have an extra subdirectory in 
> there.
>
> Try searching for "cmd.groovy" under your job directory and see where all 
> the copies are. See where there is a .svn dir vs where there is just a copy 
> and make sure that it is in the right place.
>
> -M
>
>
> On Friday, September 16, 2016 at 5:03:13 PM UTC-7, Brian Ray wrote:
>>
>> All good tips. I've been blowing away the local copy between attempts and 
>> currently have this structure (note: I changed the configured libname from 
>> *helpers 
>> *to *pipelineGlobalHelpers *in the latest attempt, and this is checking 
>> out on my local troubleshooter master right now--this is even before the 
>> first *stage *or *node *blocks):
>>
>> c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\pipelineGlobalHelpers
>> >dir
>>  Volume in drive C has no label.
>>  Volume Serial Number is 4456-EE0F
>>
>>  Directory of c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\
>> pipelineGlobalHelpers
>>
>> 2016-09-16  16:18  .
>> 2016-09-16  16:18  ..
>> 2016-09-16  16:18  resources
>> 2016-09-16  16:18  src
>> 2016-09-16  16:18  vars
>>0 File(s)  0 bytes
>>5 Dir(s)  249,994,575,872 bytes free
>>
>>
>> This 
>> <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/1b70381dbda34e6fd9acb15b4c206e9aec75c965/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryAdder.java#L147-L183>
>>  
>> is likely the method that's complaining; see the *throw *at the end.
>>
>> The thing that I am puzzling at is the construction of the directory path:
>>
>> FilePath libDir = new FilePath(execution.getOwner().getRootDir()).child(
>> "libs/" + name);
>>
>> That to me suggests it yields 
>> c:/Jenkins/workspace/Dev-Snippets/x-pipeline-1/libs/pipelineGlobalHelpers, 
>> instead of .../x-pipeline-1@libs/pipelineGlobalHelpers, but maybe I am 
>> misunderstanding *FilePath#child* or *#getRootDir*.
>>
>> There are still a few more experiments to try.
>>
>>
>> On Friday, September 16, 2016 at 4:28:05 PM UTC-7, Michael Lasevich wrote:
>>>
>>> Implicit load was to work around issues with '@Library' syntax, but I 
>>> doubt that is your issue here.
>>>
>>> I would check that your SVN URL is pointing to directory that has "vars" 
>>> in it and double-check that it is checking out the right dir. Look for 
>>> "vars" dir in  /workspace@libs/ dir in yours job and/or 
>>> "/builds/##/libs/helpers/&

Re: Pipeline external global library in SVN - errors

[Brian Ray]

All good tips. I've been blowing away the local copy between attempts and 
currently have this structure (note: I changed the configured libname from 
*helpers 
*to *pipelineGlobalHelpers *in the latest attempt, and this is checking out 
on my local troubleshooter master right now--this is even before the first 
*stage 
*or *node *blocks):

c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\pipelineGlobalHelpers>
dir
 Volume in drive C has no label.
 Volume Serial Number is 4456-EE0F

 Directory of c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\
pipelineGlobalHelpers

2016-09-16  16:18  .
2016-09-16  16:18  ..
2016-09-16  16:18  resources
2016-09-16  16:18  src
2016-09-16  16:18  vars
   0 File(s)  0 bytes
   5 Dir(s)  249,994,575,872 bytes free


This 
<https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/1b70381dbda34e6fd9acb15b4c206e9aec75c965/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryAdder.java#L147-L183>
 
is likely the method that's complaining; see the *throw *at the end.

The thing that I am puzzling at is the construction of the directory path:

FilePath libDir = new FilePath(execution.getOwner().getRootDir()).child(
"libs/" + name);

That to me suggests it yields 
c:/Jenkins/workspace/Dev-Snippets/x-pipeline-1/libs/pipelineGlobalHelpers, 
instead of .../x-pipeline-1@libs/pipelineGlobalHelpers, but maybe I am 
misunderstanding *FilePath#child* or *#getRootDir*.

There are still a few more experiments to try.


On Friday, September 16, 2016 at 4:28:05 PM UTC-7, Michael Lasevich wrote:
>
> Implicit load was to work around issues with '@Library' syntax, but I 
> doubt that is your issue here.
>
> I would check that your SVN URL is pointing to directory that has "vars" 
> in it and double-check that it is checking out the right dir. Look for 
> "vars" dir in  /workspace@libs/ dir in yours job and/or 
> "/builds/##/libs/helpers/" inside your specific build)
>
> I would also maybe wipe the local cache of the svn repo and force a full 
> checkout again.
>
> -M
>
> On Friday, September 16, 2016 at 4:12:43 PM UTC-7, Brian Ray wrote:
>>
>>
>> <https://lh3.googleusercontent.com/-lo8y6lCOagw/V9x6kpax5UI/AQo/z44qH8va24Y22p7rhBE6kwnpMvMUj3MCgCLcB/s1600/firefox_2016-09-16_15-53-14.png>
>>
>> You beat me to the post. The hyphen in the lib name *is* causing the 
>> failure to interpolate, much the same as it would in Groovy GString 
>> interpolation. (Though I think the mechanism here is different, since 
>> plugins are written in Java ... )
>>
>> The above lib config fixed the interpolation problem. But the vars/ and 
>> src/ subdirectory discovery issue pops up again.
>>
>> Started by user Brian Ray <http://cic-qa-ber:8080/user/brian66481>
>> Loading library helpers@trunk
>> Updating 
>> https://XX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers
>>  
>> <https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers>
>>  at revision '2016-09-16T15:50:21.511 -0700'
>> At revision 85052
>>
>> No changes for 
>> https://XX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers
>>  
>> <https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers>
>>  since the previous build
>> ERROR: Library helpers expected to contain at least one of src or vars 
>> directoriesorg.codehaus.groovy.control.MultipleCompilationErrorsException 
>> <http://stacktrace.jenkins-ci.org/search?query=org.codehaus.groovy.control.MultipleCompilationErrorsException>:
>>  startup failed:
>> WorkflowScript: Loading libraries failed
>>
>> 1 error
>>
>>  at 
>> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
>>  [...]
>>
>>
>>
>> I bet there is something finicky about the root directory of the SVN 
>> working copy. But I will give *Load implicitly* a shot too.
>>
>> Thanks
>>
>> On Friday, September 16, 2016 at 3:31:07 PM UTC-7, Michael Lasevich wrote:
>>>
>>> Is it possible that this is some odd issue with '-' symbols in the 
>>> library name? I would try a simpler name. Also try to implicit load to 
>>> simplify the load...
>>>
>>> -M
>>>
>>> On Friday, September 16, 2016 at 1:16:05 PM UTC-7, Brian Ray wrote:
>>>>
>>>> Evidently I cannot drive this post widget very well. The screenshots 
>>>>

Re: Pipeline external global library in SVN - errors

[Brian Ray]

<https://lh3.googleusercontent.com/-lo8y6lCOagw/V9x6kpax5UI/AQo/z44qH8va24Y22p7rhBE6kwnpMvMUj3MCgCLcB/s1600/firefox_2016-09-16_15-53-14.png>

You beat me to the post. The hyphen in the lib name *is* causing the 
failure to interpolate, much the same as it would in Groovy GString 
interpolation. (Though I think the mechanism here is different, since 
plugins are written in Java ... )

The above lib config fixed the interpolation problem. But the vars/ and 
src/ subdirectory discovery issue pops up again.

Started by user Brian Ray <http://cic-qa-ber:8080/user/brian66481>
Loading library helpers@trunk
Updating 
https://XX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers
 
<https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers>
 at revision '2016-09-16T15:50:21.511 -0700'
At revision 85052

No changes for 
https://XX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers
 
<https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers>
 since the previous build
ERROR: Library helpers expected to contain at least one of src or vars 
directoriesorg.codehaus.groovy.control.MultipleCompilationErrorsException 
<http://stacktrace.jenkins-ci.org/search?query=org.codehaus.groovy.control.MultipleCompilationErrorsException>:
 startup failed:
WorkflowScript: Loading libraries failed

1 error

at 
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
 [...]



I bet there is something finicky about the root directory of the SVN 
working copy. But I will give *Load implicitly* a shot too.

Thanks

On Friday, September 16, 2016 at 3:31:07 PM UTC-7, Michael Lasevich wrote:
>
> Is it possible that this is some odd issue with '-' symbols in the library 
> name? I would try a simpler name. Also try to implicit load to simplify the 
> load...
>
> -M
>
> On Friday, September 16, 2016 at 1:16:05 PM UTC-7, Brian Ray wrote:
>>
>> Evidently I cannot drive this post widget very well. The screenshots are 
>> best clicked in reverse order, with the last two corresponding to the *First 
>> Try*, the middle two to *Second Try*, and the first two to *First Try.*
>>
>>>
>>>

-- 
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/3e6763ba-57dc-4b6b-ae32-77f24de667ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline external global library in SVN - errors

[Brian Ray]

Evidently I cannot drive this post widget very well. The screenshots are 
best clicked in reverse order, with the last two corresponding to the *First 
Try*, the middle two to *Second Try*, and the first two to *First Try.*

On Friday, September 16, 2016 at 1:13:34 PM UTC-7, Brian Ray wrote:
>
>
> <https://lh3.googleusercontent.com/-cOqs8qVIZFw/V9xSLtq8G2I/AQE/UTCoKL_LUJ80QUiPWmkKeGc_44LHVE4sQCLcB/s1600/firefox_2016-09-16_12-47-46.png>
>
>
> <https://lh3.googleusercontent.com/-v5wiJ9Brbiw/V9xSGyCE2cI/AQA/mGc277BJX0Mua7d-fB3CR3dliZpVcMKiwCLcB/s1600/firefox_2016-09-16_12-45-42.png>
>
>
> <https://lh3.googleusercontent.com/-QJkzfyXyiVo/V9xRvTYTE-I/AP4/5tdgIij0QjEHGOC2sDft8QTSOjvyY2vzgCLcB/s1600/firefox_2016-09-16_12-43-43.png>
>
>
> <https://lh3.googleusercontent.com/-hK2XnxOedRo/V9xRZNDDdYI/AP0/4q5lbJQ-MUUGOV6iNMm6dYb8Ezxh5ilTgCLcB/s1600/firefox_2016-09-16_12-42-26.png>
>
>
> <https://lh3.googleusercontent.com/-md0RHG2UM0E/V9xPiS8kKvI/APs/-JezHMTXcG0nMLk53khbYw1vT-xtTPHBQCLcB/s1600/firefox_2016-09-16_12-35-07.png>
>
>
> <https://lh3.googleusercontent.com/-O6as9hpb8yY/V9xPSGQMMBI/APo/udS9XLDrnMAtmmlHnCxhP85sXFEsvDa7QCLcB/s1600/firefox_2016-09-16_12-33-14.png>
>
> Despite a quick runthrough from Jesse Glick at Jenkins World, I'm bumping 
> up against two different blockers trying to use an SVN repo as an external 
> global library repository with Pipeline.
>
> All plugins are up to date, and the master is running LTS 2.7.4 on Windows.
>
> In all attempts the script begins with
>
> @Library('pipeline-global-helpers') _
>
> or
>
> @Library('pipeline-global-helpers@trunk') _
>
> Neither variant made a difference.
>
> *First Try*
> This seems like the most logical configuration, with the version token in 
> the *Repository URL*.
>
> But on running the script, the token is interpreted as a literal and the 
> checkout fails:
>
>
> *Second Try*This configuration didn't make a lot of sense but I just 
> spelled out the *Repository URL* literally and put the token in the *Default 
> version* field:
>
> And strangely enough it sort of worked. It checked out the code, but then 
> could not find the subdirectories that are clearly present.
>
>
> *Third Try*Similar to the second try, I put the token in another 
> questionable field and got the same result as the second try.
>
> Can anybody see what I am doing wrong? I feel like I'm missing something 
> elementary, as Jesse Glick has tested this enhancement with an SVN repo.
>
> 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/4452ab3e-8565-4f97-bad8-6a2d9d74ec1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline external global library in SVN - errors

[Brian Ray]

Despite a quick runthrough from Jesse Glick at Jenkins World, I'm bumping 
up against two different blockers trying to use an SVN repo as an external 
global library repository with Pipeline.

All plugins are up to date, and the master is running LTS 2.7.4 on Windows.

In all attempts the script begins with

@Library('pipeline-global-helpers') _

or

@Library('pipeline-global-helpers@trunk') _

Neither variant made a difference.

*First Try*
This seems like the most logical configuration, with the version token in 
the *Repository URL*.

But on running the script, the token is interpreted as a literal and the 
checkout fails:


*Second Try*This configuration didn't make a lot of sense but I just 
spelled out the *Repository URL* literally and put the token in the *Default 
version* field:

And strangely enough it sort of worked. It checked out the code, but then 
could not find the subdirectories that are clearly present.


*Third Try*Similar to the second try, I put the token in another 
questionable field and got the same result as the second try.

Can anybody see what I am doing wrong? I feel like I'm missing something 
elementary, as Jesse Glick has tested this enhancement with an SVN repo.

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/6f51a568-caea-490a-9181-523914a757db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins-infra question: disabling email notification on watched issues.jenkins-ci.org issues

[Brian Ray]

A few weeks ago the JIRA started sending me email notifications on my 
watched issues. Is there a way to disable these notifications on my JIRA 
profile? Atlassian's doc suggests not--it advises setting up inbox filters 
or simply "un-watching" issues when they are no longer of interest.

But, maybe there's a way.

-- 
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/5b10ebf4-538e-4dc3-8fc5-50417a77cd36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Archive multiple artifacts with same name

[Brian Ray]

I can't think of a way around it without naming the artifacts slightly 
differently. That is frustrating.

On Tuesday, August 23, 2016 at 11:39:48 PM UTC-7, Sverre Moe wrote:
>
> Yes, I am using several stash with different name derived from the slave 
> name. This helps me to transfer the artifacts to our repository.
>
> However my problem is with the archive step that makes the artifacts 
> listed up in Jenkins.
> In project branch job: Last Successful Artifacts 
> In each project build: Build Artifacts
>
> If I build an RPM on SLES12 and CentOS7, then that artifact would have the 
> same name: project-1.0.0-1.x86_64.rpm
> Using the archive step would overwrite the artifact the second time I call 
> the archive step for the same named artifact.
>
> tirsdag 23. august 2016 20.53.16 UTC+2 skrev Brian Ray følgende:
>>
>> Have you looked at the stash step 
>> <https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-stash-code-stash-some-files-to-be-used-later-in-the-build>?
>>  
>> You can set an arbitrary name, which is how I got around a similar issue.
>>
>> The only downside is that the artifacts aren't saved with the build. If 
>> you need that capability there may be a way to hack that however.
>>
>> On Thursday, August 11, 2016 at 11:15:31 PM UTC-7, Sverre Moe wrote:
>>>
>>> As it stands, using archive is useless unless it can be organized by the 
>>> node it was built on. Building a single project on multiple linux 
>>> distributions will produce the same named file, but not necessary the same.
>>>
>>> mandag 13. juni 2016 10.14.39 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> As I am building on multiple slave nodes I get RPM artifacts from each 
>>>> node. Building on 4 64bit Linux OS, I will get 4 distinct artifacts with 
>>>> the same name. Using ArtifactArchiver will only archive one of those 
>>>> distinct archives and overwrite the previous archived artifact. 
>>>> Considering 
>>>> since each OS may have different versions of libraries one single artifact 
>>>> may not work on all the OS.
>>>>
>>>> Is there a way around this problem that will allow me to archive 4 
>>>> artifacts with same name?
>>>> I am using Jenkins Pipeline and performing the following step
>>>> step([$class: 'ArtifactArchiver', artifacts: '*.rpm', excludes: null, 
>>>> fingerprint: true, onlyIfSuccessful: true])
>>>>
>>>> When I was previously using Multi-configuration builds, this was not a 
>>>> problem since each configuration would show their own artifacts.
>>>>
>>>

-- 
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/2d1e86b8-cb9f-43bb-a46e-33c34bce0646%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Archive multiple artifacts with same name

[Brian Ray]

Have you looked at the stash step 
?
 
You can set an arbitrary name, which is how I got around a similar issue.

The only downside is that the artifacts aren't saved with the build. If you 
need that capability there may be a way to hack that however.

On Thursday, August 11, 2016 at 11:15:31 PM UTC-7, Sverre Moe wrote:
>
> As it stands, using archive is useless unless it can be organized by the 
> node it was built on. Building a single project on multiple linux 
> distributions will produce the same named file, but not necessary the same.
>
> mandag 13. juni 2016 10.14.39 UTC+2 skrev Sverre Moe følgende:
>>
>> As I am building on multiple slave nodes I get RPM artifacts from each 
>> node. Building on 4 64bit Linux OS, I will get 4 distinct artifacts with 
>> the same name. Using ArtifactArchiver will only archive one of those 
>> distinct archives and overwrite the previous archived artifact. Considering 
>> since each OS may have different versions of libraries one single artifact 
>> may not work on all the OS.
>>
>> Is there a way around this problem that will allow me to archive 4 
>> artifacts with same name?
>> I am using Jenkins Pipeline and performing the following step
>> step([$class: 'ArtifactArchiver', artifacts: '*.rpm', excludes: null, 
>> fingerprint: true, onlyIfSuccessful: true])
>>
>> When I was previously using Multi-configuration builds, this was not a 
>> problem since each configuration would show their own artifacts.
>>
>

-- 
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/bcb9d384-ae99-4224-a093-8e0cf142550b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File as parameter not working

[Brian Ray]

Gotcha, did not follow how you were getting it across to the build.

On Thursday, May 19, 2016 at 4:15:06 AM UTC-7, Jonathan Hodgson wrote:
>
> The remote machine currently isn't sharing the file, that's part of the 
> point of uploading it in the http POST, sorting out a share seems like it 
> would be an issue, it needs to be dynamic.
>
> On Thursday, May 19, 2016 at 2:25:47 AM UTC+1, Brian Ray wrote:
>>
>> Sorry, the API was URL#withInputStream, not #withReader.
>>
>> On Wednesday, May 18, 2016 at 6:24:11 PM UTC-7, Brian Ray wrote:
>>>
>>> Aha. Pipeline's under heavy development so unfortunately, there are gaps 
>>> like this.
>>>
>>> How's the remote machine sharing the file? Windows directory share, e.g.?
>>>
>>> Depending on the type of file and how it's shared will likely determine 
>>> the strategy. I had no success getting a pipeline script to use the Groovy 
>>> GDK URL#withReader API to slurp a file from a URL and plop it into the 
>>> workspace with the *writeFile *step but that was several revisions back 
>>> with Pipeline. Instead I do the same with a Groovy script executed via a 
>>> *sh/bat* step, inside a *node* block. But that fit my use case.
>>>
>>> On Wednesday, May 18, 2016 at 9:39:10 AM UTC-7, Jonathan Hodgson wrote:
>>>>
>>>> Thanks,
>>>>
>>>> What I've found so far also seems to indicate there is an issue with 
>>>> File Parameters in Pipeline plugins. If that's the case then it really 
>>>> begs 
>>>> the question as to why they're an option on the pipeline project setup 
>>>> page.
>>>>
>>>> I'm having trouble seeing how I'm going to do what I need to do though, 
>>>> because the file has to be provided from a remote machine in the build 
>>>> call.. it's a diff file, I need to achieve a "try before commit".
>>>>
>>>> As I said, I'm rather new to Jenkins.
>>>>
>>>> On Wednesday, May 18, 2016 at 5:14:37 PM UTC+1, Brian Ray wrote:
>>>>>
>>>>> Not 100% sure but I suspect that Pipeline job params can only be 
>>>>> "regular" String parameters and perhaps param types whose values easily 
>>>>> resolve to strings. My gut instinct is that more exotic param types that 
>>>>> have side effects--like the File type--will not work.
>>>>>
>>>>> So in the current use case the straightforward workaround would be to 
>>>>> use a String parameter to specify a filesystem path or URI, and then have 
>>>>> the Pipeline script place it in the workspace. There may be 
>>>>> Pipeline-friendly plugins that could do this for you as well, though they 
>>>>> are not coming to mind. (In our use cases all resources needed in the 
>>>>> workspace come from *checkout* steps against a source repo and some 
>>>>> custom scripting to grab binary artifacts from Artifactory.)
>>>>>
>>>>> On Wednesday, May 18, 2016 at 12:53:13 AM UTC-7, Jonathan Hodgson 
>>>>> wrote:
>>>>>>
>>>>>> Ok, I tried creating two projects, one a freestyle job, the other a 
>>>>>> pipeline.
>>>>>>
>>>>>> The only thing I set up in each was a file as parameter. I ran a 
>>>>>>  "Build using parameters" selecting the same file to upload.
>>>>>>
>>>>>> When I tried to view the file in the freestyle job, it worked, but in 
>>>>>> the pipeline job I got the same error as above.
>>>>>>
>>>>>> On Wednesday, May 18, 2016 at 2:21:11 AM UTC+1, Jonathan Hodgson 
>>>>>> wrote:
>>>>>>>
>>>>>>> I've been experimenting, and if I do what appears to be exactly the 
>>>>>>> same thing with a Freestyle project, file upload is successful.
>>>>>>>
>>>>>>> I can't state yet whether the freestyle/pipeline job difference 
>>>>>>> coinciding with a failure to upload the file is a coincidence, or the 
>>>>>>> deciding factor.
>>>>>>>
>>>>>>

-- 
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/9b26b3d0-526a-4bcd-842f-dec80958d3f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File as parameter not working

[Brian Ray]

Sorry, the API was URL#withInputStream, not #withReader.

On Wednesday, May 18, 2016 at 6:24:11 PM UTC-7, Brian Ray wrote:
>
> Aha. Pipeline's under heavy development so unfortunately, there are gaps 
> like this.
>
> How's the remote machine sharing the file? Windows directory share, e.g.?
>
> Depending on the type of file and how it's shared will likely determine 
> the strategy. I had no success getting a pipeline script to use the Groovy 
> GDK URL#withReader API to slurp a file from a URL and plop it into the 
> workspace with the *writeFile *step but that was several revisions back 
> with Pipeline. Instead I do the same with a Groovy script executed via a 
> *sh/bat* step, inside a *node* block. But that fit my use case.
>
> On Wednesday, May 18, 2016 at 9:39:10 AM UTC-7, Jonathan Hodgson wrote:
>>
>> Thanks,
>>
>> What I've found so far also seems to indicate there is an issue with File 
>> Parameters in Pipeline plugins. If that's the case then it really begs the 
>> question as to why they're an option on the pipeline project setup page.
>>
>> I'm having trouble seeing how I'm going to do what I need to do though, 
>> because the file has to be provided from a remote machine in the build 
>> call.. it's a diff file, I need to achieve a "try before commit".
>>
>> As I said, I'm rather new to Jenkins.
>>
>> On Wednesday, May 18, 2016 at 5:14:37 PM UTC+1, Brian Ray wrote:
>>>
>>> Not 100% sure but I suspect that Pipeline job params can only be 
>>> "regular" String parameters and perhaps param types whose values easily 
>>> resolve to strings. My gut instinct is that more exotic param types that 
>>> have side effects--like the File type--will not work.
>>>
>>> So in the current use case the straightforward workaround would be to 
>>> use a String parameter to specify a filesystem path or URI, and then have 
>>> the Pipeline script place it in the workspace. There may be 
>>> Pipeline-friendly plugins that could do this for you as well, though they 
>>> are not coming to mind. (In our use cases all resources needed in the 
>>> workspace come from *checkout* steps against a source repo and some 
>>> custom scripting to grab binary artifacts from Artifactory.)
>>>
>>> On Wednesday, May 18, 2016 at 12:53:13 AM UTC-7, Jonathan Hodgson wrote:
>>>>
>>>> Ok, I tried creating two projects, one a freestyle job, the other a 
>>>> pipeline.
>>>>
>>>> The only thing I set up in each was a file as parameter. I ran a 
>>>>  "Build using parameters" selecting the same file to upload.
>>>>
>>>> When I tried to view the file in the freestyle job, it worked, but in 
>>>> the pipeline job I got the same error as above.
>>>>
>>>> On Wednesday, May 18, 2016 at 2:21:11 AM UTC+1, Jonathan Hodgson wrote:
>>>>>
>>>>> I've been experimenting, and if I do what appears to be exactly the 
>>>>> same thing with a Freestyle project, file upload is successful.
>>>>>
>>>>> I can't state yet whether the freestyle/pipeline job difference 
>>>>> coinciding with a failure to upload the file is a coincidence, or the 
>>>>> deciding factor.
>>>>>
>>>>

-- 
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/85481625-dd46-4767-9fdc-aacf295e7322%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File as parameter not working

[Brian Ray]

Aha. Pipeline's under heavy development so unfortunately, there are gaps 
like this.

How's the remote machine sharing the file? Windows directory share, e.g.?

Depending on the type of file and how it's shared will likely determine the 
strategy. I had no success getting a pipeline script to use the Groovy GDK 
URL#withReader API to slurp a file from a URL and plop it into the 
workspace with the *writeFile *step but that was several revisions back 
with Pipeline. Instead I do the same with a Groovy script executed via a 
*sh/bat* step, inside a *node* block. But that fit my use case.

On Wednesday, May 18, 2016 at 9:39:10 AM UTC-7, Jonathan Hodgson wrote:
>
> Thanks,
>
> What I've found so far also seems to indicate there is an issue with File 
> Parameters in Pipeline plugins. If that's the case then it really begs the 
> question as to why they're an option on the pipeline project setup page.
>
> I'm having trouble seeing how I'm going to do what I need to do though, 
> because the file has to be provided from a remote machine in the build 
> call.. it's a diff file, I need to achieve a "try before commit".
>
> As I said, I'm rather new to Jenkins.
>
> On Wednesday, May 18, 2016 at 5:14:37 PM UTC+1, Brian Ray wrote:
>>
>> Not 100% sure but I suspect that Pipeline job params can only be 
>> "regular" String parameters and perhaps param types whose values easily 
>> resolve to strings. My gut instinct is that more exotic param types that 
>> have side effects--like the File type--will not work.
>>
>> So in the current use case the straightforward workaround would be to use 
>> a String parameter to specify a filesystem path or URI, and then have the 
>> Pipeline script place it in the workspace. There may be Pipeline-friendly 
>> plugins that could do this for you as well, though they are not coming to 
>> mind. (In our use cases all resources needed in the workspace come from 
>> *checkout* steps against a source repo and some custom scripting to grab 
>> binary artifacts from Artifactory.)
>>
>> On Wednesday, May 18, 2016 at 12:53:13 AM UTC-7, Jonathan Hodgson wrote:
>>>
>>> Ok, I tried creating two projects, one a freestyle job, the other a 
>>> pipeline.
>>>
>>> The only thing I set up in each was a file as parameter. I ran a  "Build 
>>> using parameters" selecting the same file to upload.
>>>
>>> When I tried to view the file in the freestyle job, it worked, but in 
>>> the pipeline job I got the same error as above.
>>>
>>> On Wednesday, May 18, 2016 at 2:21:11 AM UTC+1, Jonathan Hodgson wrote:
>>>>
>>>> I've been experimenting, and if I do what appears to be exactly the 
>>>> same thing with a Freestyle project, file upload is successful.
>>>>
>>>> I can't state yet whether the freestyle/pipeline job difference 
>>>> coinciding with a failure to upload the file is a coincidence, or the 
>>>> deciding factor.
>>>>
>>>

-- 
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/1c371ca9-5570-47a3-8f0d-5ac82a464288%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File as parameter not working

[Brian Ray]

Not 100% sure but I suspect that Pipeline job params can only be "regular" 
String parameters and perhaps param types whose values easily resolve to 
strings. My gut instinct is that more exotic param types that have side 
effects--like the File type--will not work.

So in the current use case the straightforward workaround would be to use a 
String parameter to specify a filesystem path or URI, and then have the 
Pipeline script place it in the workspace. There may be Pipeline-friendly 
plugins that could do this for you as well, though they are not coming to 
mind. (In our use cases all resources needed in the workspace come from 
*checkout* steps against a source repo and some custom scripting to grab 
binary artifacts from Artifactory.)

On Wednesday, May 18, 2016 at 12:53:13 AM UTC-7, Jonathan Hodgson wrote:
>
> Ok, I tried creating two projects, one a freestyle job, the other a 
> pipeline.
>
> The only thing I set up in each was a file as parameter. I ran a  "Build 
> using parameters" selecting the same file to upload.
>
> When I tried to view the file in the freestyle job, it worked, but in the 
> pipeline job I got the same error as above.
>
> On Wednesday, May 18, 2016 at 2:21:11 AM UTC+1, Jonathan Hodgson wrote:
>>
>> I've been experimenting, and if I do what appears to be exactly the same 
>> thing with a Freestyle project, file upload is successful.
>>
>> I can't state yet whether the freestyle/pipeline job difference 
>> coinciding with a failure to upload the file is a coincidence, or the 
>> deciding factor.
>>
>

-- 
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/2b2d770c-d0c0-4c9b-8424-8f9a999e3c84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Brian Ray]

Found a wrinkle 
<https://issues.jenkins-ci.org/browse/JENKINS-24805?focusedCommentId=257412=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-257412>
 
to masking secrets in the log, in one of my edge cases Pipeline.

I'm trying to determine whether this edge case warrants a JIRA.

On Wednesday, April 27, 2016 at 8:51:35 AM UTC-7, Brian Ray wrote:
>
> 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/847e4b37-9c9e-4a92-a36d-10cd1c96afab%40googlegroups.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 
> <http://stackoverflow.com/questions/15619216/groovy-scope-how-to-access-script-variable-in-a-method>
>  
> 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<Map.Entry<K,V>>* 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 
>

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<Map.Entry<K,V>>* 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 <https://issues.jenkins-ci.org/browse/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

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

[Brian Ray]

I recently started experimenting with Credentials Binding with a Pipeline 
script passing a user-password credential down to a *sh*/*bat *step inside 
a *node* block, with the secret values masked perfectly in the log. (The 
step just executed some Groovy that *println System.getenv()'d* the 
protected env variable.) In fact the masking worked so well I had to add 
some equality tests against the value to ensure that the secret value was 
indeed the right value.

Maybe my use case was different than JENKINS-24805.

On Monday, April 25, 2016 at 4:54:14 AM UTC-7, Ant Weiss wrote:
>
> Hi all,
> thanks for your inputs.
> In fact I implemented this with Credentials Binding plugin and it worked 
> great - masking the passwords as it should.
>
> On Monday, April 25, 2016 at 12:55:14 PM UTC+3, Harry G. wrote:
>>
>> Please note: Credentials Binding works, but currently it is not possible 
>> to mask passwords in the log with this solution.
>> https://issues.jenkins-ci.org/browse/JENKINS-24805
>> A PR from Cloudbees is in work, but not finished
>>
>> https://groups.google.com/forum/#!msg/jenkinsci-users/GgX3RSckVlI/LU8IqzqoMwAJ
>>
>> Until this is done, the only way to mask passwords in the log is 
>> EnvInject or MaskPassword Plugin (with their respective backdraws).
>> You could possibly externalize parts of your pipeline to a freestyle job 
>> and use them.
>>
>> Official doc suggests to turn off log (set +x), if you can do this 
>> reliably for all relevant jobs:
>>
>> https://cloudbees.zendesk.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
>> If you have several people working on build jobs/scripts I would 
>> discourage from doing this.
>>
>> Am Sonntag, 24. April 2016 16:33:22 UTC+2 schrieb Daniel Beck:
>>>
>>>
>>> > On 24.04.2016, at 14:24, Ant Weiss  wrote: 
>>> > 
>>> > What is the right way to do this when wrting pipeline DSL scripts? 
>>> > 
>>>
>>> Credentials and Credentials Binding Plugin: 
>>>
>>> https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Binding+Plugin 
>>>
>>>

-- 
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/094f4375-e30b-474a-88f3-a81d1899eb75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Where can I drop a jar for it to be generally available to jenkins?

[Brian Ray]

We download jars in the job's workspace after checking out Groovy scripts 
and set the classpath env variable prior to running the Groovy build step. 
In Freestyle jobs we use the Artifactory plugin 
 to grab 
these jars and the EnvInject plugin 
 to set the 
classpath. In our Pipeline jobs we use Groovy scripts to grab them and the 
Pipeline script to set the classpath. There are probably dozens of other 
ways to get jars to the workspace.

On Friday, April 8, 2016 at 12:45:02 PM UTC-7, Guy Matz wrote:
>
> Thanks for the reply!  I'm not actually looking to server content, if 
> that's what you're getting at.  I'm looking for a way to make a jar 
> available to groovy scripts run as a build step.
>
> Thanks again!
>
> On Fri, Apr 8, 2016 at 12:23 PM, Mark Waite  > wrote:
>
>> The userContent directory on the Jenkins server serves content over http 
>> if that would help. 
>>
>> On Fri, Apr 8, 2016 at 7:53 AM Guy Matz  
>> wrote:
>>
>>> Is there a magic directory I can put a jar for it to available to 
>>> Jenkins?  Or - ugh - Do I need to put it in a 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-use...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/CABnTgtUAMSe2FkO%3DWSOatWBrVrCaSMnp0BeVbdBH8%2BGsSJ7scQ%40mail.gmail.com
>>>  
>>> 
>>> .
>>> 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-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFRhENWv1U1-2%2BzUgYa418PbDRBsXgf%2BMeGJXGevWnayA%40mail.gmail.com
>>  
>> 
>> .
>> 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/1d9088a0-b1c6-46b7-b4b0-5bf10cde9f65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question regarding Jenkins pipeline setup

[Brian Ray]

Interesting. We have not got to using the Jenkinsfile "discovery" 
functionality yet, but this is good to know. I'll keep my eyes open for 
more on this subdirectory.

On Friday, April 1, 2016 at 12:49:46 PM UTC-7, tomwils...@gmail.com wrote:
>
>  Thank you Brian, you're right regarding the @tmp directory.  However 
> the @script directory seems to be different.
>  I'm searching in the source code of the workflow cps plugin.  The 
> file CpsScmFlowDefinition.java seems to be the place where the 
> workspace@script behavior is implemented.  It seems that it use this 
> mechanism to checkout and search the entire repository for the Jenkinsfile. 
>  I didn't look very careful at this code yet but it make me concern a 
> little bit about the efficiency of this operation.  If in order to search 
> for the Jenkinsfile, it has to check out the entire repository then it 
> would be quite slow for big repository.  I wonder whether some repository 
> has option to simply search the file inside or not and whether Jenkins 
> actually implements this functionality this way.
>
> Tom
>
> On Friday, April 1, 2016 at 11:07:41 AM UTC-5, Brian Ray wrote:
>>
>> https://issues.jenkins-ci.org/browse/JENKINS-27152
>>
>> I'm not sure about @script but suspect it's a similar necessity.
>>
>> On Friday, April 1, 2016 at 12:00:18 AM UTC-7, tomwils...@gmail.com 
>> wrote:
>>>
>>> Hello,
>>>I'm trying to setup Jenkins to run a multibranch pipeline project. 
>>>  Just to test, I use a very simple Jenkinsfile like this:
>>>
>>> node {
>>> checkout scm
>>> bat 'echo > tst1.txt'
>>> }
>>>
>>> When I run the build, for each branch, for example the 'master' branch, 
>>> Jenkins creates 3 directories:
>>> - workspace@script: contains source code.  This is created first even 
>>> before the node statement is executed.
>>> - workspace: contains source code.  This is created with the node 
>>> statement
>>> - workspace@tmp: empty.  This is created when running 'bat' command.
>>>
>>>
>>> - Certainly I do not need 2 copies of the source code so I don't need 
>>> the workspace@script directories but this is created automatically and I do 
>>> not know how to turn it off.  The default directory when inside the node 
>>> command block is 'workspace', not 'workspace@script' so I can't do anything 
>>> with the source unless I change directory to workspace@script.  Is there 
>>> anyway so that Jenkins does not check out the workspace@script directory?
>>>
>>> - What is the purpose of workspace@tmp? and is there a way not to create 
>>> it as well?
>>>
>>> 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/ab38cbdc-de1a-4d40-9cf8-b157af7a9a3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins.io blog RSS feed link incorrect?

[Brian Ray]

Thanks. Surprised I stumbled across it first.

On Friday, April 1, 2016 at 9:40:33 AM UTC-7, R Tyler Croy wrote:
>
> (replies inline) 
>
> On Fri, 01 Apr 2016, Brian Ray wrote: 
>
> > The RSS feed link <https://feeds.feedburner.com/~r/ContinuousBlog/> on 
> the 
> > new Jenkins blog page <https://jenkins.io/node/> seems to have some 
> lint in 
> > the URL that causes Feedburner to return an HTTP error 400. However if I 
> > remove that bit of lint and use a clean URL for the feed 
> > <https://feeds.feedburner.com/ContinuousBlog/>, all is good. 
> > 
> > Is this a bug in that link? I searched for an issue on 
> > issues.jenkins-ci.org but came up with nothing. 
>
>
> It does look like that's a bug, I've fixed it and the site is regenerating 
> now. 
>
>
>
> - R. Tyler Croy 
>
> -- 
>  Code: <https://github.com/rtyler> 
>   Chatter: <https://twitter.com/agentdero> 
>
>   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F 
> -- 
>

-- 
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/a3d51e0a-dcf9-4737-9028-ad96180e3445%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jenkins.io blog RSS feed link incorrect?

[Brian Ray]

The RSS feed link  on the 
new Jenkins blog page  seems to have some lint in 
the URL that causes Feedburner to return an HTTP error 400. However if I 
remove that bit of lint and use a clean URL for the feed 
, all is good.

Is this a bug in that link? I searched for an issue on 
issues.jenkins-ci.org but came up with nothing.

-- 
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/e6fea490-f12c-49cf-a59e-4d9fc5b7e30d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question regarding Jenkins pipeline setup

[Brian Ray]

https://issues.jenkins-ci.org/browse/JENKINS-27152

I'm not sure about @script but suspect it's a similar necessity.

On Friday, April 1, 2016 at 12:00:18 AM UTC-7, tomwils...@gmail.com wrote:
>
> Hello,
>I'm trying to setup Jenkins to run a multibranch pipeline project. 
>  Just to test, I use a very simple Jenkinsfile like this:
>
> node {
> checkout scm
> bat 'echo > tst1.txt'
> }
>
> When I run the build, for each branch, for example the 'master' branch, 
> Jenkins creates 3 directories:
> - workspace@script: contains source code.  This is created first even 
> before the node statement is executed.
> - workspace: contains source code.  This is created with the node statement
> - workspace@tmp: empty.  This is created when running 'bat' command.
>
>
> - Certainly I do not need 2 copies of the source code so I don't need the 
> workspace@script directories but this is created automatically and I do not 
> know how to turn it off.  The default directory when inside the node 
> command block is 'workspace', not 'workspace@script' so I can't do anything 
> with the source unless I change directory to workspace@script.  Is there 
> anyway so that Jenkins does not check out the workspace@script directory?
>
> - What is the purpose of workspace@tmp? and is there a way not to create 
> it as well?
>
> 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/5d2827d9-0952-4b24-a62f-65cde6c5e79d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best Practices with LTS Updates

[Brian Ray]

+1 to what Chris said.

Two more cents worth of advice: When I upgrade one of our Jenkins masters 
(on LTS) I first look at the changelogs to have some idea of the delta-- 
potential gotchas, new features to evangelize, etc. Aside from critical 
security releases I typically wait a day or two after the LTS release is 
available in the unlikely event that the LTS release is not S(table). 
That's never been the case, but my bias is very conservative for this 
particular Jenkins master.

On Wednesday, March 16, 2016 at 5:51:42 PM UTC-7, Christopher Orr wrote:
>
> On 14/03/16 19:36, Mark Bidewell wrote: 
> > I am managing the Jenkins Server for my company.  Recently, we moved 
> > from 1.609.3 to 1.625.3.  I noticed however that the Required Core 
> > Dependencies for Pipe line skipped 1.625.x and went from 1.609.1 to 
> 1.642.1. 
> > 
> > What are the best practices for selecting LTS versions to update?  Would 
> > an upgrade from say 1.609.3 to 1.642.2 be safe? 
>
> You're already on LTS, so there aren't many more "best practices", other 
> than update regularly :) 
>
> But there should generally be no problem with upgrading between releases 
> that are relatively close like those two are. 
>
> Regards, 
> Chris 
>

-- 
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/b62523a0-5e08-477d-baac-498a3722%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Groovy+pipeline: why does executing step exit function?

[Brian Ray]

It's because of the *@NonCPS* annotation. It's incompatible with pipeline 
step calls. See more here 
.

On Thursday, February 4, 2016 at 8:45:21 AM UTC-8, Oleh Olkhovskyy wrote:
>
> Hi,
>
> I'm writing a pipeline groovy script. and stumbled upon this problem:
>
> If I try to run step within a function, then function is immediately 
> terminated and doesn't execute following instructions.
> I.e.
>
> I have function:
>
> @NonCPS
> def getBuildOutput(build_job) {
> echo "BeforeStep"
> def prop_file=readFile('get_src_job_artifacts/output.properties')
> echo "AfterStep"
> //Execute further processing with non serializable variables
> //
>
>
> But when I call it, "BeforeStep" is echoed, but "AfterStep" is not.
> instead getBuildOutput returns string read from that file.
> Why is that, and is there a way to avoid that?
>
>
>
>

-- 
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/8ea9c94f-67ca-4abc-80ab-841a6c97e22d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow plugin] use case question

[Brian Ray]

Can you just set the *Restrict where this project can be run* checkbox in 
conjunction with the *Label Expression* param on the two subjobs?

On Thursday, January 21, 2016 at 2:16:39 AM UTC-8, Patrick Bruneton wrote:
>
> Hi all,
>
> I am trying to implement a use case with the workflow plugin.
> I have two jobs, say build & test, that I want to run inside a pipeline. 
> Sounds easy.
> But I have a constraint:I want the two jobs to executed on the same slave.
> So I tried something like this:
>
> node('windows') {
>stage name: 'Build', concurrency: 1
>build 'build'
>stage name: 'Test', concurrency: 1
>build 'test'
> }
>
>
> But 'build' and 'test' are executed in their own slave, which is not the 
> one allocated by 'node'. That seems logical.
> Is there a way to force the builds to run a node?
>
> I understand I could(/should) write the job logic directly in the 
> pipeline, e.g.
>
> node('windows') {
>stage name: 'Build', concurrency: 1
>// build stage details
>stage name: 'Test', concurrency: 1
>// test stage details
> }
>
> However, I am not sure I can do this, because my jobs exist already, and 
> use plugins that do not seem to be supported by workflow (e.g. xUnit, 
> Extended Email)
>
> Any thought?
>
> Thanks,
> Patrick
>

-- 
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/ecced7f3-ac77-4698-8837-2fb609822094%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Master/Slave configurations

[Brian Ray]

Assuming you mean mixed Windows/Linux environments, yes. Our shop has both 
1) Windows and 2) Linux (CentOS) masters with both 1) Windows and Linux 
slaves, and 2) Windows slaves.

On Monday, January 11, 2016 at 10:15:07 AM UTC-8, techi...@gmail.com wrote:
>
> Hello All,
>
> In jenkins can we have master/slave configurations in windows and linux 
> vice versa.
>
> Appreciate your inputs
>

-- 
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/c6639eac-cdc4-4abf-b6b0-8fd8b4b607fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Approaches for sharing workspace in a pipeline

[Brian Ray]

Ah yes, that help seems a little misleading with the wording "May take a 
*mapping* parameter ..."

On Sunday, December 27, 2015 at 8:02:36 PM UTC-8, John D. Ament wrote:
>
> Ok, so I think I got something.  If I use "**/*" on the unarchive step, I 
> get everything.  Not quite what I expected, but it works.
>
>
>
> On Thursday, December 24, 2015 at 1:20:16 PM UTC-5, John D. Ament wrote:
>>
>> Creating the archive doesn't seem to be an issue.
>>
>> Its the unarchive step where things don't quite work for me.  If I read 
>> this info, it implies that the mapping step is not required.  
>> https://github.com/jenkinsci/workflow-plugin/blob/master/basic-steps/src/main/resources/org/jenkinsci/plugins/workflow/steps/ArtifactUnarchiverStep/config.jelly#L31
>>
>> However, if mapping isn't set, an exception gets thrown: 
>> https://github.com/jenkinsci/workflow-plugin/blob/master/basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/ArtifactUnarchiverStepExecution.java#L39
>>
>> And in fact, the expanding of the archive is keyed off of this mapping 
>> config.  
>> https://github.com/jenkinsci/workflow-plugin/blob/master/basic-steps/src/main/java/org/jenkinsci/plugins/workflow/steps/ArtifactUnarchiverStepExecution.java#L42
>>
>> It looks like it may be straight forward enough to add an unarchive all 
>> option, and if that works I may try that out instead.
>>
>> John
>>
>> On Thursday, December 24, 2015 at 12:55:30 PM UTC-5, Brian Ray wrote:
>>>
>>> Isn't the "get everything" Ant regex something like  or ***/**?
>>>
>>> If you continue looking at workflow, also check out the *stash* and 
>>> *unstash 
>>> *steps. Similar purpose and syntax but more applicable to intermediate 
>>> stages where you don't need to retain the artifacts. You can also refer to 
>>> the batch of *stash*ed artifacts by an arbitrary logical name for 
>>> downstream *unstash*ing.
>>>
>>> On Thursday, December 24, 2015 at 6:53:56 AM UTC-8, John D. Ament wrote:
>>>>
>>>> Hi,
>>>>
>>>> I definitely thought about workflow.  It looks promising.
>>>>
>>>> One question though - I can't seem to archive/unarchive everything.  It 
>>>> looks like to use unarchiver you need to know the paths that will be 
>>>> exposed, and instead I'd like to just get everything, including class 
>>>> files.  Is that possible?
>>>>
>>>> John
>>>>
>>>> On Thursday, December 24, 2015 at 1:49:01 AM UTC-5, Baptiste Mathus 
>>>> wrote:
>>>>>
>>>>> Hi John,
>>>>>
>>>>> Not sure what you call a pipeline job, do you mean 'workflow job'? or 
>>>>> do you use the term in a generic way and actually have many (freestyle) 
>>>>> jobs you're coordinating?
>>>>>
>>>>> If the latter, then it really seems like a use case for a workflow job 
>>>>> (using the workflow plugin). Using/archiving etc. artifacts and being 
>>>>> able 
>>>>> to share the ws during the build is gonna be both more natural and more 
>>>>> maintainable (and more robust because of the durability).
>>>>>
>>>>> My 2 cents
>>>>> Le 24 déc. 2015 3:46 AM, "John D. Ament" <john.d...@gmail.com> a 
>>>>> écrit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was wondering if anyone had any best practices or tips to share on 
>>>>>> have a common workspace for a pipeline job.
>>>>>>
>>>>>> Basically, I have a series of pipeline jobs and I want them to have a 
>>>>>> single workspace for the duration of the job chain.  I compile the 
>>>>>> artifacts once, running unit tests, followed by a suite of integration 
>>>>>> and 
>>>>>> BDD tests.  It's a fairly complicated build, including generating an app 
>>>>>> server and minifying a lot of javascript for our UI.  Some of these 
>>>>>> steps 
>>>>>> are pretty long, and in total we have 4 pipeline steps.  I figure by 
>>>>>> doing 
>>>>>> this once, I would cut out about 40 minutes of rebuild time in my 
>>>>>> pipeline.
>>>>>>
>>>>>> One idea I had was to use the clone workspace plugin to copy them, 
>>>>>> https://wiki.jenkins-ci.org/display/JEN

Re: Approaches for sharing workspace in a pipeline

[Brian Ray]

Isn't the "get everything" Ant regex something like  or ***/**?

If you continue looking at workflow, also check out the *stash* and *unstash 
*steps. Similar purpose and syntax but more applicable to intermediate 
stages where you don't need to retain the artifacts. You can also refer to 
the batch of *stash*ed artifacts by an arbitrary logical name for 
downstream *unstash*ing.

On Thursday, December 24, 2015 at 6:53:56 AM UTC-8, John D. Ament wrote:
>
> Hi,
>
> I definitely thought about workflow.  It looks promising.
>
> One question though - I can't seem to archive/unarchive everything.  It 
> looks like to use unarchiver you need to know the paths that will be 
> exposed, and instead I'd like to just get everything, including class 
> files.  Is that possible?
>
> John
>
> On Thursday, December 24, 2015 at 1:49:01 AM UTC-5, Baptiste Mathus wrote:
>>
>> Hi John,
>>
>> Not sure what you call a pipeline job, do you mean 'workflow job'? or do 
>> you use the term in a generic way and actually have many (freestyle) jobs 
>> you're coordinating?
>>
>> If the latter, then it really seems like a use case for a workflow job 
>> (using the workflow plugin). Using/archiving etc. artifacts and being able 
>> to share the ws during the build is gonna be both more natural and more 
>> maintainable (and more robust because of the durability).
>>
>> My 2 cents
>> Le 24 déc. 2015 3:46 AM, "John D. Ament"  a écrit :
>>
>>> Hi,
>>>
>>> I was wondering if anyone had any best practices or tips to share on 
>>> have a common workspace for a pipeline job.
>>>
>>> Basically, I have a series of pipeline jobs and I want them to have a 
>>> single workspace for the duration of the job chain.  I compile the 
>>> artifacts once, running unit tests, followed by a suite of integration and 
>>> BDD tests.  It's a fairly complicated build, including generating an app 
>>> server and minifying a lot of javascript for our UI.  Some of these steps 
>>> are pretty long, and in total we have 4 pipeline steps.  I figure by doing 
>>> this once, I would cut out about 40 minutes of rebuild time in my pipeline.
>>>
>>> One idea I had was to use the clone workspace plugin to copy them, 
>>> https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin, 
>>> but it seems like this isn't pipeline sensitive since each step in the 
>>> pipeline should be building the same commit.  I also thought about copying 
>>> artifacts, but it seems like its a huge number of artifacts.  Could I build 
>>> a zip with the contents?
>>>
>>> Any thoughts?
>>>
>>> Thanks!
>>>
>>> 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-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/3c25d084-56c8-4242-a6e0-a0b347ea0af8%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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/efb5de9c-5c33-46dd-a443-4761652f7c20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cucumber reporting graphs not showing

[Brian Ray]

Awesome. We've opened up that filter a bit to accomodate some CSS and 
column sort scripting with the Cucumber Reports pages, but still have Flash 
content blocked. So no bouncing pie charts for us for the time being.

On Thursday, December 17, 2015 at 4:09:39 AM UTC-8, donovan.b...@gmail.com 
wrote:
>
> This works great now thanks! Our version of Jenkins is 1.642 so is 
> affected by the new security features which did indeed break Cucumber 
> Reports.
>
> For clarification for others, i edited /etc/sysconfig/jenkins and added 
> -Dhudson.model.DirectoryBrowserSupport.CSP= to JENKINS_JAVA_OPTIONS to get 
> around the restrictions.
>

-- 
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/ceababd5-4af8-40f6-87fc-0f7da62e8a1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass values from Shell script to Workflow script in Jenkins Workflow plugin

[Brian Ray]

We're using this technique too and I think it's the only hack available for 
the time being.

JENKINS-26133  may some 
day yield a more elegant, native way to get results back out to the 
workflow.

On Thursday, December 17, 2015 at 8:51:00 AM UTC-8, B.Latinville wrote:
>
> If you have not found yet, this could help you : 
>
>
> https://github.com/jenkinsci/workflow-examples/blob/master/workflow-examples/gitcommit/gitcommit.groovy
>
>

-- 
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/a0ae0c2e-6de3-4702-9590-29bd6d971021%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cucumber reporting graphs not showing

[Brian Ray]

Which release of the Jenkins master are you running? The most recent 
versions of the release and LTS release introduced this security feature 

 
that, by default, disables most inline and non-domain scripting, CSS, etc 
when viewed in most up to date browsers.

With respect to Cucumber Reports, that generally means the animated pie 
charts at the top of the report are suppressed, as well as column sorting, 
some styling, etc., depending on the browser used.

On Wednesday, December 16, 2015 at 3:13:16 AM UTC-8, donovan.b...@gmail.com 
wrote:
>
> Hi, We have created a job which succeeds and creates a 
> cucumber-html-reports directory on the master. When locally accessing these 
> files the graphs display perfectly.
>
> However, if I click on Cucumber Reports in Jenkins, the graphs do not show 
> and the graphics around the statistics table do not show. If I view it in 
> Chrome, it only displays HTML text and no graphics whatsoever.
>
> As i say, the HTML files are fine if you access them locally so its just 
> not rendering it if called from within Jenkins.
>
> 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/e1ae9cdb-351f-41f2-9731-e8e981dc4345%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Groovy Question: revision from job?

[Brian Ray]

My approach has just been iteratively trying things with the Script Console 
up in one window and the Javadoc up in other windows. I'm unsure if there 
is an easier way to learn it.

On Thursday, December 10, 2015 at 6:18:28 AM UTC-8, Guy Matz wrote:
>
> Nicely done!!  How the heck was I supposed to know that!?  :-(  The API is 
> less than intuitive and does not seem to be well documented.  Any advice on 
> how to best use it?
>
> Thanks again!!
>
> On Wed, Dec 9, 2015 at 7:28 PM, Christopher Orr  > wrote:
>
>> Hi there,
>>
>> On 09/12/15 23:40, Guy Matz wrote:
>> > Hi!  Anyone know how I can retrieve the git revision from a job?
>> >
>> > I can get to the build:
>> >
>> > j = Jenkins.instance.getJob('render-master')
>> > b475 = j.getBuildByNumber(475)
>> >
>> > but I can't find a way to to get the git revision associated with that
>> > build.  Any thoughts would be appreciated!
>>
>> Git metadata is stored in a `BuildData` action, so something like this
>> (untested) should work:
>>
>>
>> b475.getAction(hudson.plugins.git.util.BuildData.class).lastBuiltRevision.sha1String
>>
>> Regards,
>> Chris
>>
>> --
>> 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/5668C714.30504%40orr.me.uk
>> .
>> 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/dfa91529-2347-493c-83e1-8065e5d07491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reuse workflow code across workflow jobs

[Brian Ray]

Avoided the global library myself for similar reasons. There is an issue in 
the Jenkins Jira  that 
covers broadly what you are looking for, I think.

On Friday, November 13, 2015 at 6:38:50 AM UTC-8, Martin d'Anjou wrote:
>
> Is there a way groovy workflow scripts from the "Workflow script from SCM" 
> could import classes from their own cloned path, or be able to do something 
> similar to the Gradle "apply from: 'other.gradle'"?
>
> I read about the Workflow Global Library, but that seems like an 
> additional Git repository to me.
>
>

-- 
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/5ba96bd5-bde1-40b7-af16-5eddb1b54bbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: kill a job

[Brian Ray]

This article mentions workflow jobs, but should work for any kind of job:

https://cloudbees.zendesk.com/hc/en-us/articles/204453080-Unable-to-kill-a-Workflow-job-that-is-stuck-executing-

On Wednesday, November 11, 2015 at 1:29:44 AM UTC-8, TZ wrote:
>
> Hi
> I got stuck job that i need to abort.i cancel the build but it dosent stop 
>
> Its stuck on starting of a another plugin. its been 5-6 hrs now but it 
> didnt stop 
>
> Can some one help 
>
> 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/f96b65f6-b6c4-4caf-93dc-da2ce41e5ada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow-plugin] parallel threads greater than matching node label executors silently discard unassigned threads

[Brian Ray]

Neglected to mention:

Workflow plugin: 1.10.1


On Monday, November 9, 2015 at 3:49:27 PM UTC-8, Brian Ray wrote:
>
> My pilot project flow spreads work across a pool of single-executor 
> general purpose slaves like the following very simple example:
>
> // Assume 'taskDoers' label includes two nodes, one executor each
> final tasks = [
>   task0: {
> node('taskDoers') {
>   // do some stuff
> }
>   },
>   task1: {
> node('taskDoers') {
>   // do some other stuff
> }
>   },
>   task2: {
> node('taskDoers') {
>   // do still more stuff
> }
>   },
> ]
>
> parallel tasks
>
> But that leaves an odd branch out, the third. Which seems to be silently 
> discarded (never scheduled or executed), as far as I can tell. The main 
> flow console is something like the following:
>
> Running: Change Directory : Start
> Running in C:\Jenkins\workspace\pilot-flow@2\plans
> Running: Change Directory : Body : Start
> Running: Read file from workspace
> Running: Read file from workspace
> Running: Change Directory : Body : End
> Running: Change Directory : End
> Running: Allocate node : Body : End
> Running: Allocate node : End
> Running: Pick
> Entering stage Pick
> Proceeding
> Running: Execute sub-workflows in parallel : Start
> [task0] Running: Parallel branch: task0
> [task1] Running: Parallel branch: task1
> [task0] Running: Allocate node : Start
> [task0] Running on taskDoer-02 in C:\Jenkins\workspace\pilot-flow@2
> [task1] Running: Allocate node : Start
> [task1] Running on taskDoer-01 in C:\Jenkins\workspace\pilot-flow@2
> [task0] Running: Allocate node : Body : Start
> [task1] Running: Allocate node : Body : Start
> [task0] Running: Print Message
> [task0] Doing a bunch of important work
> Running: Allocate node : Body : End
> [task1] Running: Print Message
> [task1] Doing still more important work
> Running: Allocate node : Body : End
> Running: Allocate node : End
> Running: Allocate node : End
> Running: Execute sub-workflows in parallel : Body : End
> Running: Execute sub-workflows in parallel : Body : End
> Running: Execute sub-workflows in parallel : End
> Running: End of Workflow
> Finished: SUCCESS
>
>
> Is this a bug? A feature? I can envision a workaround, which is to size up 
> the pool of nodes with a matching label and then chunk up groups of threads 
> to spread evenly across that pool, executing parallel steps in sequence.
>
> For this project, we're running:
>
> LTS 1.625.1 <http://jenkins-ci.org/>
> Master: Windows Server 2008 R2
> Master: JDK 1.8.0.45 JRE
> Slaves: mix of Windows Server 2008 R2 Standard and Enterprise
> Slaves: mix of 1.7.0.458 JRE, 1.7.0.710 JRE, and 1.7.0.210 JRE
>
>

-- 
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/db822ac1-c2eb-4840-8527-8f89702f1736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[workflow-plugin] parallel threads greater than matching node label executors silently discard unassigned threads

[Brian Ray]

My pilot project flow spreads work across a pool of single-executor general 
purpose slaves like the following very simple example:

// Assume 'taskDoers' label includes two nodes, one executor each
final tasks = [
  task0: {
node('taskDoers') {
  // do some stuff
}
  },
  task1: {
node('taskDoers') {
  // do some other stuff
}
  },
  task2: {
node('taskDoers') {
  // do still more stuff
}
  },
]

parallel tasks

But that leaves an odd branch out, the third. Which seems to be silently 
discarded (never scheduled or executed), as far as I can tell. The main 
flow console is something like the following:

Running: Change Directory : Start
Running in C:\Jenkins\workspace\pilot-flow@2\plans
Running: Change Directory : Body : Start
Running: Read file from workspace
Running: Read file from workspace
Running: Change Directory : Body : End
Running: Change Directory : End
Running: Allocate node : Body : End
Running: Allocate node : End
Running: Pick
Entering stage Pick
Proceeding
Running: Execute sub-workflows in parallel : Start
[task0] Running: Parallel branch: task0
[task1] Running: Parallel branch: task1
[task0] Running: Allocate node : Start
[task0] Running on taskDoer-02 in C:\Jenkins\workspace\pilot-flow@2
[task1] Running: Allocate node : Start
[task1] Running on taskDoer-01 in C:\Jenkins\workspace\pilot-flow@2
[task0] Running: Allocate node : Body : Start
[task1] Running: Allocate node : Body : Start
[task0] Running: Print Message
[task0] Doing a bunch of important work
Running: Allocate node : Body : End
[task1] Running: Print Message
[task1] Doing still more important work
Running: Allocate node : Body : End
Running: Allocate node : End
Running: Allocate node : End
Running: Execute sub-workflows in parallel : Body : End
Running: Execute sub-workflows in parallel : Body : End
Running: Execute sub-workflows in parallel : End
Running: End of Workflow
Finished: SUCCESS


Is this a bug? A feature? I can envision a workaround, which is to size up 
the pool of nodes with a matching label and then chunk up groups of threads 
to spread evenly across that pool, executing parallel steps in sequence.

For this project, we're running:

LTS 1.625.1 
Master: Windows Server 2008 R2
Master: JDK 1.8.0.45 JRE
Slaves: mix of Windows Server 2008 R2 Standard and Enterprise
Slaves: mix of 1.7.0.458 JRE, 1.7.0.710 JRE, and 1.7.0.210 JRE

-- 
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/8aef7648-866f-4956-b915-813afac8cda2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow-plugin] Hack to unstash outside of a node block?

[Brian Ray]

Here's the hack. The example assumes I don't need the files as such in the 
main workflow, just the contents:

def planNumberOne
node('planners') {

  // ...
  // slurp up the file and pass it "outside" the block
  planNumberOne = readFile 'plans/plan_1'

}

// Lo and behold, the override sticks back out here in the main flow. 
// This variable is not null, it has the contents of plans/plan_1 and 
// the echo displays them.
echo planNumberOne

I did not expect it to work nor understand why it works. I knew you could 
pass an outer workflow variable into the *node* block but thought this was 
a one-way street. Ie that the block could see the value and possibly 
override it, but that the workflow would retain the original value.

On Friday, October 30, 2015 at 9:40:02 AM UTC-7, Brian Ray wrote:
>
> The *unstash *step outside of a *node *block is illegal, because it wants 
> a workspace to unstash to:
>
> node('planners') {
>
>   // ...
>   // do a bunch of stuff then stash the product
>   stash( name: 'plans', includes: 'plans/*' )
>
> }
>
> // this is unwrapped and will throw a MissingContextVariableException
> unstash 'plans'
>
> Is there a hack to *unstash *files out into the main workflow, or an 
> equivalent that doesn't use *stash *and *unstash*? I'm attempting to 
> offload some of the planning and preparation for downstream flow logic into 
> the *planners *pool at the top of the flow. The main workflow would then 
> use that output to split out chunks of work via *parallel*.
>

-- 
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/dde23bec-7be9-41fc-a652-09ec55227d35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[workflow-plugin] Hack to unstash outside of a node block?

[Brian Ray]

The *unstash *step outside of a *node *block is illegal, because it wants a 
workspace to unstash to:

node('planners') {

  // ...
  // do a bunch of stuff then stash the product
  stash( name: 'plans', includes: 'plans/*' )

}

// this is unwrapped and will throw a MissingContextVariableException
unstash 'plans'

Is there a hack to *unstash *files out into the main workflow, or an 
equivalent that doesn't use *stash *and *unstash*? I'm attempting to 
offload some of the planning and preparation for downstream flow logic into 
the *planners *pool at the top of the flow. The main workflow would then 
use that output to split out chunks of work via *parallel*.

-- 
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/4331968d-ebd4-45ea-8fd3-5889498bd6ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow] Generating parallel branches causes job to hang

[Brian Ray]

See this earlier thread for the Iterator serialization issue:

https://groups.google.com/d/msg/jenkinsci-users/LGRv7Jq60YI/ZN-68zuw2loJ

On Wednesday, October 14, 2015 at 10:33:41 AM UTC-7, Michael Štědrý wrote:
>
> Hi Andres,
>
> I've got one more interesting thing for you. I managed to get your sample 
> working even though I had to remove the functions:
>
> def testList = "test1 test2".split()
> def branches = [:]
> for (int i = 0; i < testList.length; i++) {
> def testName = testList[i];
> branches[testName] = {
> echo testName
> sleep 20
> }
> }
> parallel branches
>
> What I found out is that I couldn't use the nice for loop because it fails 
> with:
>
> java.io.NotSerializableException: java.util.AbstractList$Itr
>
> ...
>
> Caused by: an exception which occurred:
>   in field itr
>   in field target
>   in field continue_
>   in field parent
>   in field capture
>   in field def
>   in field closures
>   in object org.jenkinsci.plugins.workflow.cps.CpsThreadGroup@8b36066
>
>
> And when I put the creation of the branches in a function it started to 
> behave strangely.
>
>
> On Sunday, September 27, 2015 at 10:25:47 PM UTC+2, Andres Rodriguez wrote:
>>
>> Hi Everyone,
>>
>> First of all, I want to say that I'm really enjoying the workflow plugin. 
>> Thanks for all the effort in bringing this feature to production. Specially 
>> loading the DSL file from a git repository allows us to auto-test our 
>> changes to a job through the same mechanism that we test changes to the 
>> code (using Gerrit).
>>
>> I'm currently encountering some weird behavior when generating a list of 
>> tests parallel branches dynamically. I've boiled it down to the following 
>> small test case that you can paste into the workflow script box:
>>
>> @NonCPS
>> def generateTestBranches (testList) {
>> def branches = [:]
>> for (testName in testList.split()) {
>> branches[testName] = {
>> echo testName
>> sleep 20
>> }
>> }
>> return branches
>> }
>>
>> def runTests (testList) {
>> def testBranches = generateTestBranches(testList)
>> parallel testBranches
>> }
>>
>> runTests "test1 test2"
>>
>> The output of this job (it can't be aborted):
>>
>> Running: Execute sub-workflows in parallel : Start
>> [test1] Running: Parallel branch: test1
>> Aborted by anonymous 
>> Aborted by anonymous 
>> Aborted by anonymous 
>>
>>
>> I've also tried replacing the "parallel testBranches" with a simple loop 
>> to execute the closures in the map manually (my understanding is that 
>> map.each is broken atm so I used a loop instead):
>>
>> for ( test in testBranches) {
>>  echo "executing ${test.key}"
>>  test.value()
>> }
>>
>> And the output is as follows (note that it prints test2 instead of test1 
>> from inside the closure):
>>
>> Started by user anonymous 
>> Running: Print Message
>> executing test1
>> Running: Print Message
>> test2
>> Running: Print Message
>> executing test2
>> Running: Print Message
>> test2
>> Running: End of Workflow
>> Finished: SUCCESS
>>
>>
>> I'm not a Groovy expert (I just started learning for the workflow 
>> plugin), so I might be doing something dumb here. I'm trying to read the 
>> groovy docs to figure out if the way I'm generating the closure is an 
>> issue. But overall the state the system gets into seems to be pretty bad 
>> (can't abort the job). So I wanted to send out an email here just in case 
>> this is a problem with the Jenkins groovy core.
>>
>> Thanks again for the constant improvements to the workflow plugin.
>>
>> Regards,
>> Andres
>>
>>
>>

-- 
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/a38e1340-2591-4560-aaaf-fb74d51b1918%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Templates Plugin (Jenkins Enterprise)

[Brian Ray]

Aha. Got it.

On Tuesday, October 6, 2015 at 11:06:33 AM UTC-7, Daniel Beck wrote:
>
>
> On 06.10.2015, at 18:52, Brian Ray <be_...@sbcglobal.net > 
> wrote: 
>
> > Not to drag the thread off-topic, but could you elaborate on any 
> security issues with Job DSL? I experimented with it a while back, and 
> CloudBees is going to demo Job Templates to my shop in the near future, but 
> is there something that makes Job DSL inherently less secure-able than the 
> latter? 
> > 
> > For example, couldn't you just use project-based security to lock down 
> the Job DSL job that creates and updates the spawned jobs? 
>
> The problem is that a user with Job/Configure on a single freestyle job 
> can add a Job DSL build step there, and wreaks havoc on your instance.

-- 
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/291d4a1e-9f71-430c-9017-a5a85dad6871%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Templates Plugin (Jenkins Enterprise)

[Brian Ray]

Not to drag the thread off-topic, but could you elaborate on any security 
issues with Job DSL? I experimented with it a while back, and CloudBees is 
going to demo Job Templates to my shop in the near future, but is there 
something that makes Job DSL inherently less secure-able than the latter?

For example, couldn't you just use project-based security to lock down the 
Job DSL job that creates and updates the spawned jobs?

Thanks,

On Friday, October 2, 2015 at 12:57:59 PM UTC-7, Baptiste Mathus wrote:
>
> +1 for the Job DSL plugin if you don't have hard security requirements on 
> your Jenkins instance. (i.e. all users are allowed to modify anything).
>
> 2015-10-02 20:37 GMT+02:00 Cuong Tran :
>
>> Martin,
>>
>> We use the Templates plugin to simplify the job creation interface and 
>> standardize common job types. Combined with the folder plugin, we can 
>> restrict what can be created within a folder, making it even simpler for 
>> end users. The xml transformation isn't bad since you can just create a job 
>> with substitution tokens (${FOO}) and load it in from the interface. 
>> Changes to a template are automatically propagated to its jobs as well.  
>> You can also easily convert an existing job to use templates job.
>>
>> I think it's better than the other options you listed.
>>
>> Having said that, we have thousands of jobs and multiple Jenkins masters 
>> so this plugin doesn't work that well for our scenario.  I think the 
>> general direction of keeping the job configuration in SCM (using 
>> combination of the workflow and Job DSL plugin) is more scalable and it's 
>> something we are investigating.
>>
>> On Thursday, October 1, 2015 at 12:53:36 PM UTC-7, Martin B. wrote:
>>>
>>> Hello users. 
>>>
>>> I'm looking for independent opinions on the Jenkins Enterprise Templates 
>>> Plugin. 
>>>
>>> It would be one of the main reasons for us to adopt Jenkins Enterprise, 
>>> but I was quite shocked to learn (see 
>>>
>>> http://documentation.cloudbees.com/docs/cje-user-guide/temolate-sect-job-template-tutorial.html)
>>>  
>>>
>>> that you actually have to do raw XML transformation to get a simple job 
>>> template running. Looks rather bare bones to me. ('course I *can* see 
>>> where this might be useful with very complicated job templates, but I 
>>> like to keep the simple stuff simple, and telling people to write jelly 
>>> transformations isn't my idea of simple) 
>>>
>>> Anyway - are you using JE Templates Plugin? Great Stuff? Much better 
>>> than (https://github.com/JoelJ/ez-templates) or 
>>> (https://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin) 
>>> ... ? 
>>>
>>> cheers, 
>>> Martin 
>>>
>> -- 
>> 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/6a363e9f-ed64-4be8-a4a9-7dc68591c6d6%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

-- 
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/603addc4-2433-412f-85a3-cd31eb19a41b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Another Jenkins server as backup

[Brian Ray]

The last chapter of the book Jenkins: The Definitive Guide 
http://www.amazon.com/Jenkins-Definitive-John-Ferguson-Smart/dp/1449305350 
describes a few practices that, if used together, would give you something 
like a cold or warm Jenkins master mirror.

Failover however would not be automatic or instant. But it would be free 
in the sense of no software license.

On Tuesday, August 18, 2015 at 11:34:42 PM UTC-7, Pulkit Lall wrote:

 After spending some time I also heard of HA. Any idea regarding this or 
 where can I find proper documentation for this process?

 On Thursday, 13 August 2015 23:03:31 UTC+5:30, Wei-min Lee wrote:

 If there's concern about jobs in flight, then periodic versioning of the 
 matter config and files cannot address the requirement. HA is what would 
 address a live failover requirement.



-- 
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/8bb6a8ef-3e18-41ac-8d23-eb392c32c100%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JUC West - Sept 2 3, 2015

[Brian Ray]

Thanks for clearing that up!

Brian

On Wednesday, August 19, 2015 at 11:44:00 AM UTC-7, Alyssa Tong wrote:

 yes. JUC https://www.cloudbees.com/jenkins/juc-2015/us-west attendee 
 will be able to cross attend the CD Summit 
 https://www.cloudbees.com/cdsummit/us-west at not additional charge. 

 The CD Summit is gear toward IT execs and technologists. JUC is gear 
 toward Jenkins Users, consisting of practitioners/ developers.

 thnx
 alyssa

 On Wed, Aug 19, 2015 at 11:29 AM, Brian Ray be_...@sbcglobal.net 
 javascript: wrote:

 On a related topic, does registration at the JUC give you access to the 
 concurrent CD Summi http://page.cloudbees.biz/XlY09xK0I000ZD8SF001Pw0t? 
 I received an email for it that suggests registering for CD gives you 
 access to JUC, they both happen at the SC Convention center, seem targeted 
 to the same audience ...

 Confused as to why there are two distinct events.

 Thanks

 On Tuesday, August 18, 2015 at 1:15:09 PM UTC-7, Alyssa Tong wrote:

 Hello,

 We're only 2 weeks away from JUC Santa Clara 
 https://www.cloudbees.com/jenkins/juc-2015/us-west. If you haven't 
 registered 
 https://www.regonline.com/Register/Checkin.aspx?EventID=1697214 pls 
 do so as soon as possible as the event is almost sold out.  Take advantage 
 of the 2 for 1 deal..bring a friend and pay for the price of 1. 

 Come and learn how MicroSoft, AWS, Google, Yahoo!, and VMWare (just to 
 name a few) are using Jenkins. And best of all, network and meet the 
 prominent Jenkins members, they will be staffing the Ask the Expert booth.

 Special thanks to our Ask the Expert panelists:

- Owen Mehegan
- Daniel Beck
- Mark Waite
- Kohsuke Kawaguchi
- Andrew Bayer
- Jesse Glick
- Vincent Latombe

 *Bonus:*
 CloudBees and Sonatype are hosting the DevOps Wine-ing 
 http://page.cloudbees.biz/DPW000R0ZKY00G01YI0o0lj (NOT whining!) 
 event at the Hyatt Regency, connected to the Santa Clara Convention 
 Center. If you're already in town for the Jenkins User Conference 
 http://page.cloudbees.biz/dl0Yo1RIGj0ZY00K0M000P0  or just local to 
 the area, join fellow Jenkins and DevOps practitioners on Tuesday, 
 September 1, for a fun evening with drinks and apps in the Terra Courtyard. 
 Space 
 is limited, so please *register* 
 http://page.cloudbees.biz/DPW000R0ZKY00G01YI0o0lj ahead of time to 
 ensure entry. It's FREE!

 See you in a couple of weeks!

 Alyssa

 -- 
 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 javascript:.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/70efad97-002c-42a2-b6a4-a8feaa13b6f8%40googlegroups.com
  
 https://groups.google.com/d/msgid/jenkinsci-users/70efad97-002c-42a2-b6a4-a8feaa13b6f8%40googlegroups.com?utm_medium=emailutm_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/803c19f4-0598-4eef-aa83-79a35895f17d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Discard only some artifacts?

[Brian Ray]

You could probably use a Console/Scriptler script to do the cleanup via the 
Hudson/Jenkins API, and in fact IIRC there are a couple Scriptler scripts 
that do things along these lines.

On Thursday, August 6, 2015 at 8:21:05 AM UTC-7, matthew...@diamond.ac.uk 
wrote:

 I'm aware of the options for keeping old builds but deleting old 
 artifacts. 
 I have a slightly different requirement: I want to delete _some_ of the 
 artifacts from old builds, but keep the builds themselves plus some of the 
 artifacts. 
 My artifacts comprise some large binaries (which I don't need to keep for 
 very long), plus a few text files describing the build, which need to be 
 kept (along with the build log, test results etc). 

 At the moment, we have a bash script that runs nightly and deletes the 
 large artifacts according to some rule. 
 Can anyone suggest a more Jenkins-ish way of doing this? 

 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/894fd064-3403-4bab-b78b-f26fb969000a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Difference in behavior of PluginWrapper.getDependencies() and UpdateSite.Plugin.dependencies

[Brian Ray]

Transitive dependencies for the first API seems like the best bet. I tried 
to trace them manually but at that point I was going cross-eyed walking the 
graph.

Thanks

On Tuesday, August 4, 2015 at 2:31:37 PM UTC-7, James Nord wrote:

 the former looks should include all transative deps which will likely 
 incluce the dependencies that are bundled with Jenkins core for the version 
 of jenkins you target (like junit that used to not be a plugin).

 The UpdateSite should match exactly the json from the updateCenter.

 On Monday, 3 August 2015 17:37:08 UTC+1, Brian Ray wrote:

 Can anybody explain the difference in behavior between these two APIs? 
 The only thing that I can make out is that UpdateSite's dependency 
 properties seem to mirror exactly the dependencies declared in each 
 plugin's MANIFEST.MF file. The PluginWrapper APIs usually return more 
 dependencies, but the nature of the extra dependencies returned is 
 unclear. I thought perhaps it was transitive dependencies but tracing 2nd- 
 and N-order dependencies of a few plugins by hand didn't seem to reflect 
 that.

 Here's an example console script:

 final plug = 'nodelabelparameter'
 println Plugin-Plugin Dependencies for $plug:\n

 println 'PluginManager/PluginWrapper'
 println '-' * 80
 println Jenkins.instance.pluginManager.getPlugin(plug).dependencies
 println Jenkins.instance.pluginManager.getPlugin(plug).
 optionalDependencies

 println '\nUpdateCenter/UpdateSite.Plugin'
 println '-' * 80
 println Jenkins.instance.updateCenter.getPlugin(plug).dependencies
 println Jenkins.instance.updateCenter.getPlugin(plug).
 optionalDependencies

 println '\nUpdateCenter/UpdateSite.Plugin alt'
 println '-' * 80
 println Jenkins.instance.updateCenter.getPlugin(plug).
 getNeededDependencies()


 And output:

 Plugin-Plugin Dependencies for nodelabelparameter:

 PluginManager/PluginWrapper
 
 [token-macro (1.9), jquery (1.7.2-1), parameterized-trigger 
 (2.22;resolution:=optional), matrix-auth (1.0.2), windows-slaves (1.0), 
 antisamy-markup-formatter (1.0), matrix-project (1.0), junit (1.0)]
 [parameterized-trigger (2.22;resolution:=optional), matrix-auth (1.0.2), 
 windows-slaves (1.0), antisamy-markup-formatter (1.0), matrix-project (1.0), 
 junit (1.0)]

 UpdateCenter/UpdateSite.Plugin
 
 [token-macro:1.9, jquery:1.7.2-1]
 [parameterized-trigger:2.22]

 UpdateCenter/UpdateSite.Plugin alt
 
 []





-- 
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/8ca3bfa4-a272-4bab-b146-498b0310705b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Difference in behavior of PluginWrapper.getDependencies() and UpdateSite.Plugin.dependencies

[Brian Ray]

Can anybody explain the difference in behavior between these two APIs? The 
only thing that I can make out is that UpdateSite's dependency properties 
seem to mirror exactly the dependencies declared in each plugin's 
MANIFEST.MF file. The PluginWrapper APIs usually return more dependencies, 
but the nature of the extra dependencies returned is unclear. I thought 
perhaps it was transitive dependencies but tracing 2nd- and N-order 
dependencies of a few plugins by hand didn't seem to reflect that.

Here's an example console script:

final plug = 'nodelabelparameter'
println Plugin-Plugin Dependencies for $plug:\n

println 'PluginManager/PluginWrapper'
println '-' * 80
println Jenkins.instance.pluginManager.getPlugin(plug).dependencies
println Jenkins.instance.pluginManager.getPlugin(plug).optionalDependencies

println '\nUpdateCenter/UpdateSite.Plugin'
println '-' * 80
println Jenkins.instance.updateCenter.getPlugin(plug).dependencies
println Jenkins.instance.updateCenter.getPlugin(plug).optionalDependencies

println '\nUpdateCenter/UpdateSite.Plugin alt'
println '-' * 80
println Jenkins.instance.updateCenter.getPlugin(plug).getNeededDependencies
()


And output:

Plugin-Plugin Dependencies for nodelabelparameter:

PluginManager/PluginWrapper

[token-macro (1.9), jquery (1.7.2-1), parameterized-trigger 
(2.22;resolution:=optional), matrix-auth (1.0.2), windows-slaves (1.0), 
antisamy-markup-formatter (1.0), matrix-project (1.0), junit (1.0)]
[parameterized-trigger (2.22;resolution:=optional), matrix-auth (1.0.2), 
windows-slaves (1.0), antisamy-markup-formatter (1.0), matrix-project (1.0), 
junit (1.0)]

UpdateCenter/UpdateSite.Plugin

[token-macro:1.9, jquery:1.7.2-1]
[parameterized-trigger:2.22]

UpdateCenter/UpdateSite.Plugin alt

[]



-- 
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/8ee26d84-5ef5-4c53-85bc-26279ad706ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Manual build step support

[Brian Ray]

There is a simple step available in the worfklow plugin called input.

https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md#pausing-flyweight-vs-heavyweight-executors
 
But it would require your job to be a worfklow job and does not support a 
very sophisticated input form, AFAIK.

On Friday, July 31, 2015 at 10:09:23 AM UTC-7, Peter Hayes wrote:

 Hi,

 I am doing a proof of concept of codifying our delivery pipeline within 
 Jenkins.  We have a number of our stages automated but we do have a couple 
 stages that require manual inspection of the software.  I was thinking that 
 it would be cool if there was a build step type that you could configure 
 for a job (call the job manual-testing) and when run, the job would 
 essentially pause waiting for user input that the manual testing completed. 
  The confirmation screen would accept file uploads to the workspace, the 
 build result, and a log entry.  When submitted, the job would then continue 
 with post build actions as a normal fully automated job execution would. It 
 could then generate reports and fit nicely into the overall delivery 
 pipeline.  

 I did some plugin searching and came up empty - could mean I am out in 
 left field on this, but the more I think about it the more interested I am 
 in having this capability.  Does anyone know if something like this exists?

 Thanks,
 Pete


-- 
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/8610e7d8-663f-41f4-9910-09d7d2dd7ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[workflow-plugin] Does Groovy CPS DSL from SCM only support Git?

[Brian Ray]

In experimenting with my first workflow project I switched over from 
editing straight in the project config to *Groovy CPS DSL from SCM*. The UI 
displayed all the expected SCM flavors: Git, SVN, CVS, etc. We're an SVN 
shop so I chose that and filled out the checkout details. After saving and 
coming back into the job config, however, the *SCM* dropdown had switched 
to Git and subsequently displayed only Git, obscuring all my SVN settings.

I replicated this issue and noted that under the covers, in the job's 
config.xml, it still seems to be configured for SVN despite the behavior of 
the UI. Note I did not specify any particular SVN parameters this second 
time so most of the properties are empty:

  definition class=
org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition plugin=
workflow-cps@1.8
scm class=hudson.scm.SubversionSCM plugin=subversion@1.54
  locations/
  excludedRegions/excludedRegions
  includedRegions/includedRegions
  excludedUsers/excludedUsers
  excludedRevprop/excludedRevprop
  excludedCommitMessages/excludedCommitMessages
  workspaceUpdater class=hudson.scm.subversion.UpdateUpdater/
  ignoreDirPropChangesfalse/ignoreDirPropChanges
  filterChangelogfalse/filterChangelog
/scm
scriptPathflow.groovy/scriptPath
  /definition


We're running Jenkins 1.609.1 and workflow-plugin 1.8.

-- 
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/c69bb0d6-9b00-421f-8060-4b0ef916d0f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [workflow-plugin] Does Groovy CPS DSL from SCM only support Git?

[Brian Ray]

Never mind, I think the Subversion plugin is way out of date--no workflow 
support as of that old version.

On Friday, July 24, 2015 at 2:57:31 PM UTC-7, Brian Ray wrote:

 In experimenting with my first workflow project I switched over from 
 editing straight in the project config to *Groovy CPS DSL from SCM*. The 
 UI displayed all the expected SCM flavors: Git, SVN, CVS, etc. We're an SVN 
 shop so I chose that and filled out the checkout details. After saving and 
 coming back into the job config, however, the *SCM* dropdown had switched 
 to Git and subsequently displayed only Git, obscuring all my SVN settings.

 I replicated this issue and noted that under the covers, in the job's 
 config.xml, it still seems to be configured for SVN despite the behavior of 
 the UI. Note I did not specify any particular SVN parameters this second 
 time so most of the properties are empty:

   definition class=
 org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition plugin=
 workflow-cps@1.8
 scm class=hudson.scm.SubversionSCM plugin=subversion@1.54
   locations/
   excludedRegions/excludedRegions
   includedRegions/includedRegions
   excludedUsers/excludedUsers
   excludedRevprop/excludedRevprop
   excludedCommitMessages/excludedCommitMessages
   workspaceUpdater class=hudson.scm.subversion.UpdateUpdater/
   ignoreDirPropChangesfalse/ignoreDirPropChanges
   filterChangelogfalse/filterChangelog
 /scm
 scriptPathflow.groovy/scriptPath
   /definition


 We're running Jenkins 1.609.1 and workflow-plugin 1.8.


-- 
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/74121be0-630a-4ed3-9120-d808112466ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cannot run groovy on node

[Brian Ray]

Good news. I'll look for that next time we update our servers.

Thanks

On Tuesday, July 14, 2015 at 2:09:46 PM UTC-7, Daniel Beck wrote:

 It should only be the UI label by now (pending a new Groovy plugin 
 release), the update center provides the correct Bintray URLs: 


 http://jenkins.mirror.isppower.de/updates/updates/hudson.plugins.groovy.GroovyInstaller.json
  

 On 14.07.2015, at 18:26, Brian Ray be_...@sbcglobal.net javascript: 
 wrote: 

  Or rather, like this for 2.4.3: 
  
  
  
  
  
  
  
  
  
  On Tuesday, July 14, 2015 at 9:23:05 AM UTC-7, Brian Ray wrote: 
  
  
  codehaus.org no longer hosts the Groovy project or its binaries. 
 Configure an installer like this: 
  
  
  
  On Tuesday, July 14, 2015 at 6:36:48 AM UTC-7, Gilad Baruchian wrote: 
  I tried to configure auto install like this : 
  
  
  and i configured the job to use groovy-2-4-3, didn't work - did not 
 try to install and did not find groovy. 
  i installed groovy myself on the node, added it to the path, deleted the 
 node from jenkins and configured again, ran the job, saw the groovy on the 
 path variable in the job in jenkins, still it cannot find groovy. 
  
  I have no more ideas, 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-use...@googlegroups.com javascript:. 
  To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/1e058f52-f4cd-410c-a602-d0fbc0aa5b8a%40googlegroups.com.
  

  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/eedeb3fd-b267-490e-b2ce-eb7cd2700b68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cannot run groovy on node

[Brian Ray]

https://lh3.googleusercontent.com/-lDGZF6rMsfw/VaU3CjhUYVI/AKU/9Cne6mRwG_I/s1600/SS-2015-05-04_14.48.33.png
codehaus.org no longer hosts the Groovy project or its binaries. Configure 
an installer like this:



On Tuesday, July 14, 2015 at 6:36:48 AM UTC-7, Gilad Baruchian wrote:

 I tried to configure auto install like this :

 and i configured the job to use groovy-2-4-3, didn't work - did not try 
 to install and did not find groovy.
 i installed groovy myself on the node, added it to the path, deleted the 
 node from jenkins and configured again, ran the job, saw the groovy on the 
 path variable in the job in jenkins, still it cannot find groovy.

 I have no more ideas, 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/aa54c5f0-ef1d-42c5-9274-bfde94a8865e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cannot run groovy on node

[Brian Ray]

Or rather, like this for 2.4.3:


https://lh3.googleusercontent.com/-ezw537Qk3Ik/VaU4IcAmrII/AKg/8jKPwbSn0wo/s1600/SS-2015-07-14_09.20.05.png




On Tuesday, July 14, 2015 at 9:23:05 AM UTC-7, Brian Ray wrote:


 https://lh3.googleusercontent.com/-lDGZF6rMsfw/VaU3CjhUYVI/AKU/9Cne6mRwG_I/s1600/SS-2015-05-04_14.48.33.png
 codehaus.org no longer hosts the Groovy project or its binaries. 
 Configure an installer like this:



 On Tuesday, July 14, 2015 at 6:36:48 AM UTC-7, Gilad Baruchian wrote:

 I tried to configure auto install like this :

 and i configured the job to use groovy-2-4-3, didn't work - did not try 
 to install and did not find groovy.
 i installed groovy myself on the node, added it to the path, deleted the 
 node from jenkins and configured again, ran the job, saw the groovy on the 
 path variable in the job in jenkins, still it cannot find groovy.

 I have no more ideas, 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/1e058f52-f4cd-410c-a602-d0fbc0aa5b8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Run subjobs but disregard the result in the parent job

[Brian Ray]

Aha, yes the switch in my screenshot only satisfies the first part of 2. 
Downstream subjobs run but the parent job still is marked as FAILED--at 
least in the multijob I'm working with.

There doesn't seem to be another switch to suppress the subjob's failure 
bubbling up to the overall status in the parent.

On Thursday, May 21, 2015 at 12:03:34 AM UTC-7, Radu Codrin Leterna wrote:

 This is not exactly what I am trying to accomplish. I need to do the 
 following:
 1. Have one main job with 5 sub-jobs in a MultiJob Phase
 2. If one particular sub-job fails, just ignore that result, run all other 
 sub-jobs and DO NOT MARK the main job as failed based on that particular 
 sub-job result.

 Not sure if Jenkins can do that, even with the help of plugins. I might 
 have to modify the sub-job to PASS every time... so it does not mark the 
 parent as FAILED.

 On Wednesday, May 20, 2015 at 6:58:45 PM UTC+3, Brian Ray wrote:


 https://lh3.googleusercontent.com/-8aepTvtIBMU/VVyvKKfZ9fI/AJc/Y9rtv4yOuSU/s1600/SS-2015-05-20_08.54.32.png
 Darnit, pasting my screenshot didn't work. Let me try again:



 On Wednesday, May 20, 2015 at 8:56:42 AM UTC-7, Brian Ray wrote:

 Assuming you're using the multijob plugin, be sure to set this field to 
 *Completed* for this subproject (phase) in question:



 On Wednesday, May 20, 2015 at 8:05:10 AM UTC-7, Radu Codrin Leterna 
 wrote:

 Hello,

 I need to setup a main job that will trigger a couple sub-jobs.
 I am using a multijob-phase to trigger the sub-projects. The 
 requirement is to ignore the result from *one* of the sub-jobs 
 (whether it fails or passes, the parent should just ignore that).

 How can this be accomplished?



-- 
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/bb2850c9-5e68-421f-b25d-fab9d8d00b5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Run subjobs but disregard the result in the parent job

[Brian Ray]

Assuming you're using the multijob plugin, be sure to set this field to 
*Completed* for this subproject (phase) in question:



On Wednesday, May 20, 2015 at 8:05:10 AM UTC-7, Radu Codrin Leterna wrote:

 Hello,

 I need to setup a main job that will trigger a couple sub-jobs.
 I am using a multijob-phase to trigger the sub-projects. The requirement 
 is to ignore the result from *one* of the sub-jobs (whether it fails or 
 passes, the parent should just ignore that).

 How can this be accomplished?


-- 
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/7fb523d0-9ae9-4068-adbe-223e76964928%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Run subjobs but disregard the result in the parent job

[Brian Ray]

https://lh3.googleusercontent.com/-8aepTvtIBMU/VVyvKKfZ9fI/AJc/Y9rtv4yOuSU/s1600/SS-2015-05-20_08.54.32.png
Darnit, pasting my screenshot didn't work. Let me try again:



On Wednesday, May 20, 2015 at 8:56:42 AM UTC-7, Brian Ray wrote:

 Assuming you're using the multijob plugin, be sure to set this field to 
 *Completed* for this subproject (phase) in question:



 On Wednesday, May 20, 2015 at 8:05:10 AM UTC-7, Radu Codrin Leterna wrote:

 Hello,

 I need to setup a main job that will trigger a couple sub-jobs.
 I am using a multijob-phase to trigger the sub-projects. The requirement 
 is to ignore the result from *one* of the sub-jobs (whether it fails or 
 passes, the parent should just ignore that).

 How can this be accomplished?



-- 
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/cc8f65aa-fa3a-4d5f-acc3-bae3b8f26f7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: workflow-plugin Serialisation issues when iterating over a list of strings

[Brian Ray]

Hi Robin,

The simplest Groovy idiom for iterating over a collection is

hostnames.each { host -
  do something interesting with host ...
}



Does this work?

Brian

On Monday, February 9, 2015 at 5:48:11 AM UTC-8, Robin Tegg wrote:

 Hi all,

 I've been trying out the workflow plugin after watching the 
 pimp-your-continuous-delivery-pipeline-with-jenkins-workflow-wjax-14 
 http://www.slideshare.net/cloudbees/pimp-your-continuous-delivery-pipeline-with-jenkins-workflow-wjax-14
  demo. 
 And in one of the slides (24), there is an example of a for loop that looks 
 to iterate over a list of hostnames. I've assumed that hostnames is a list

 def hostnames = [192.168.0.1, 192.168.0.2]
 for( def hostname: hostnames ) {
 sh ssh ${hostname} ...
   }

 I'm wondering if anyone can help with my usage of arrays/lists. I'm 
 getting the following errors when I try the above:

 java.io.NotSerializableException: java.util.AbstractList$Itr


 Now I understand from the docs 
 (https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md#serialization-of-local-variables)
  that some variables can't be serialized before a sh step might happen, but 
 as I'm new to groovy I'm struggling to understand how the above might be 
 achieved. I've tried in a method and inline as suggested.


 The workaround I have at the moment is


 def hostnames = [192.168.0.1, 192.168.0.2]
 for( int i = 0; i  hostnames.size(); i++) {
   sh ssh ${hostnames.get(i)} ...
 }

 Any pointers would be much appreciated

 Thanks
 Robin


-- 
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/9dde8b3d-04a5-4644-96a0-2930f78c4978%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: workflow-plugin Serialisation issues when iterating over a list of strings

[Brian Ray]

Another stab in the dark. The double quotes mean the individual hostnames 
are GStrings instead of Strings. Maybe starting this way:

def hostnames = ['192.168.0.1', '192.168.0.2']


On Monday, February 9, 2015 at 9:25:52 AM UTC-8, Brian Ray wrote:

 Hi Robin,

 The simplest Groovy idiom for iterating over a collection is

 hostnames.each { host -
   do something interesting with host ...
 }



 Does this work?

 Brian

 On Monday, February 9, 2015 at 5:48:11 AM UTC-8, Robin Tegg wrote:

 Hi all,

 I've been trying out the workflow plugin after watching the 
 pimp-your-continuous-delivery-pipeline-with-jenkins-workflow-wjax-14 
 http://www.slideshare.net/cloudbees/pimp-your-continuous-delivery-pipeline-with-jenkins-workflow-wjax-14
  demo. 
 And in one of the slides (24), there is an example of a for loop that looks 
 to iterate over a list of hostnames. I've assumed that hostnames is a list

 def hostnames = [192.168.0.1, 192.168.0.2]
 for( def hostname: hostnames ) {
 sh ssh ${hostname} ...
   }

 I'm wondering if anyone can help with my usage of arrays/lists. I'm 
 getting the following errors when I try the above:

 java.io.NotSerializableException: java.util.AbstractList$Itr


 Now I understand from the docs 
 (https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md#serialization-of-local-variables)
  that some variables can't be serialized before a sh step might happen, 
 but as I'm new to groovy I'm struggling to understand how the above might be 
 achieved. I've tried in a method and inline as suggested.


 The workaround I have at the moment is


 def hostnames = [192.168.0.1, 192.168.0.2]
 for( int i = 0; i  hostnames.size(); i++) {
   sh ssh ${hostnames.get(i)} ...
 }

 Any pointers would be much appreciated

 Thanks
 Robin



-- 
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/42fa62f1-128d-471a-9fc1-d37fdbc0761f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.