[JIRA] (JENKINS-29188) api URL for REST API is not available for flowGraphTable
Title: Message Title Thomas Dalton commented on JENKINS-29188 Re: api URL for REST API is not available for flowGraphTable @James Sandlin: I'm not sure what you mean wrt the sandboxing - in terms of script functions we do need to whitelist some operations yes, but once done these operations can be used repeatedly. We pushed a .groovy file to workflowlibs.git that collects data that we need and builds reports that get emailed out. My suggesting was that you could do similar and push specific data elsewhere e.g. to a wider team if necessary (making sure that the information is appropriate and not sensitve with regard to your security concerns of course . Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-29188) api URL for REST API is not available for flowGraphTable
Title: Message Title Thomas Dalton commented on JENKINS-29188 Re: api URL for REST API is not available for flowGraphTable @James Sandlin . Access to pipeline result/logging data was a priority for us, so in the end we wrote wrapper scripts (bash/python) that did the bulk of the work and piped logging output to files, implementing a groovy class that dealt with the collection of results, archiving logs, and generating nicely formatted email reports tailored to meet our needs. in the end this offered us greater flexibility and control in terms of what gets reported and where vs the stock support. So if the official/unofficial REST APIs don't provide what you need I guess you could go down a similar route i.e. explicitly call functions at points in the groovy pipeline code that are responsible for "publishing" status (to interested users, perhaps beyond a firewall) at particular points in the flow. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-30363) Logo for Workflow feature
Title: Message Title Thomas Dalton commented on JENKINS-30363 Re: Logo for Workflow feature [~greiber] - I'm easily pleased. I'm happy if I've got an icon for the pipeline stuff that I can put in presentations. Looks like it is some sort of pipe Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-30363) Logo for Jenkins Worflow Plugin
Title: Message Title Thomas Dalton created an issue Jenkins / JENKINS-30363 Logo for Jenkins Worflow Plugin Issue Type: New Feature Assignee: Jesse Glick Components: workflow-plugin Created: 09/Sep/15 11:10 AM Environment: N/A Priority: Trivial Reporter: Thomas Dalton The Workflow Plugin is so useful and distinct from the rest of Jenkins it would be nice for it to have its own branding/logo e.g. for presentations etc. Add Comment
[JIRA] [workflow-plugin] (JENKINS-29188) api URL for REST API is not available for flowGraphTable
Title: Message Title Thomas Dalton commented on JENKINS-29188 Re: api URL for REST API is not available for flowGraphTable Yes these are effectively 2 things/requests: For #1 yes exposing API of the flow graph and all information it contains (console log snippets etc) would be what we're after. For #2 this is a request for more, customizable, state to be reflected through the API. So that in your workflow you can expose state for the steps and augment the flow graph with more information. I see that work has started on a "step-api" which is pleasing to see, perhaps these 2 things can be considered here? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-29188) api URL for REST API is not available for flowGraphTable
Title: Message Title Thomas Dalton created an issue Jenkins / JENKINS-29188 api URL for REST API is not available for flowGraphTable Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 02/Jul/15 1:36 PM Environment: Jenkins 1.617 Workflow 1.8 Labels: workflow rest Priority: Minor Reporter: Thomas Dalton The REST API isn't available for access to step state through the workflow running steps page. e.g. at http://server:8080//job/job name/job num/flowGraphTable/api I would expect to see a REST API page, indeed there is a link at the bottom of the flowGraphTable page to the REST API page that does not exist. At the JUC in London Jesse told me that this was probably just a bug, but if you want to make this a feature/improvement request that's fine too In general I think it would be massively useful to have access to stateful information for the workflow
[JIRA] [workflow-plugin] (JENKINS-27965) Can't trigger workflow job as job from freestyle or multijob project
Thomas Dalton edited a comment on JENKINS-27965 Cant trigger workflow job as job from freestyle or multijob project Ok thanks for the explanation - it is a shame because I want to combine my workflow with build parameters Moreover the Monitor plugin (which I'd quite like to use) doesn't appear to recognise workflow jobs - could this be related too? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27965) Can't trigger workflow job as job from freestyle or multijob project
Thomas Dalton commented on JENKINS-27965 Cant trigger workflow job as job from freestyle or multijob project That's odd because I wasn't trying a parameterized trigger directly - I thought I was trying a regular trigger! Though my setup does have the parameterized trigger plugin installed, could this be the cause? Moreover the Monitor plugin (which I'd quite like to use) doesn't appear to recognise workflow jobs - could this be related too? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27965) Can't trigger workflow job as job from freestyle or multijob project
Thomas Dalton created JENKINS-27965 Cant trigger workflow job as job from freestyle or multijob project Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 15/Apr/15 8:38 PM Description: I can't appear to directly trigger a workflow job from another project with Trigger/call builds on other projects in the Build options. In the multijob case after configuration the workflow job is not listed in the dashboard for the job - and the workflow job is not triggered. For the freestyle case the workflow job is not run either but it does return the following error: ERROR: Build aborted. Can't trigger undefined projects. 1 of the below project(s) can't be resolved: MyWorkflow Check your configuration! Yet the MyWorkflow workflow project is clearly available. I'm assuming this is just not something that is yet supported by the workflow plugin, but it would be nice if it were. In the meantime I'm working around the problem by setting up my jenkins server to point to localhost as a remote jenkins server and triggering the workflow job as a remote parameterized build. This seems to work, but I lose the context of triggering the job directly within another job. Environment: Jenkins 1.609 Workflow 1.5 Project: Jenkins Priority: Minor Reporter: Thomas Dalton This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27927) Use of interface in workflow scripts wont compile
Thomas Dalton
created JENKINS-27927
Use of interface in workflow scripts wont compile
Issue Type:
New Feature
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
14/Apr/15 12:09 PM
Description:
Since class inheritance is not available to groovy workflow scripts, I thought I'd try some alternatives, so I gave "interfaces" a go instead. I want to specify an interface that provides the templating for a common behavior I want to achieve.
e.g. MyFoo.groovy could implement an interface specified in Foo.groovy. Other scripts e.g. Bar.groovy could then invoke a common interface specified in YourFoo.groovy, MyFoo.groovy, RonaldsFoo.groovy and so on.
In trying out a very simple example of an interface to achieve what I want, the groovy-cps compiler errors.
Here is the valid groovy code that I tried (and works) under a groovy console:
interface Foo {
String name()
}
b = [name: {return "Ronald"}]
a = b as Foo
println a.name()
return
This prints "Ronald" as you'd expect.
The code that I tried in an example workflow, I was hoping could do the same, but does not:
node {
b = [name: {return "Ronald"}]
a = b as Foo
echo a.name()
}
interface Foo {
String name()
}
The error that is thrown when I hit "Apply" after entering the code in the Groovy CPS DSL box is:
javax.servlet.ServletException: java.lang.NullPointerException: Cannot invoke method visit() on null object
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123)
at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120)
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
at
[JIRA] [workflow-plugin] (JENKINS-27927) Some interface idioms do not work in Groovy CPS
Thomas Dalton
commented on JENKINS-27927
Some interface idioms do not work in Groovy CPS
I'm glad the intention is aligned with the desire to have these groovy language features available and understand that support for interface will require work in the groovy CPS.
In the short term though, is there a recommended workaround that could provide some interface like equivalent? Or is it just not possible to do anything like this at this stage?
Perhaps pass HashMaps of Closures between the top level "classes" as per
https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md#writing-shared-code
e.g.
org/foo/Zot.groovy
package org.foo
// Closures define the interface for Zot
Closure show
Closure name
def specify_interface (Hashmap hm) {
this.show = hm["show"]
this.name = hm["name"]
}
flow.groovy
node {
def z = new org.foo.Zot()
z.specify_interface(["show": { echo "Hello" }, "name": { return "Bernard" }])
// you can then pass z around beyond the scope of flow.groovy
z.show()
echo z.name()
}
Or is there a more elegant way within the constraints of what is and what is not possible today?
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) stage concurrency allows 1 thread to be blocked at a time, others fail and hang job
Thomas Dalton
commented on JENKINS-27905
stage concurrency allows 1 thread to be blocked at a time, others fail and hang job
A stage within parallel could be a common use-case for CI. For example, a given workflow may need multiple builds as well as multiple independent tests, all of which could run in parallel on the same server - each of these flows could easily benefit from having stages.
You could work around this by defining flows for each of the parallel builds, and then kicking these off e.g.
parallel([build_1: {build job: "FooFlow"}, build_2: {build job: "BarFlow"}])
Where FooFlow and BarFlow could identify their own stages, but this would require further setup on the jenkins server, more jobs to configure, and detract from the usefulness of the workflow-plugin to do this programmatically.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27927) Some interface idioms do not work in Groovy CPS
Thomas Dalton commented on JENKINS-27927 Some interface idioms do not work in Groovy CPS Hi Jesse, Thanks for getting back to me again. The reason I'm looking at the workflow-plugin is because it allows a programmatic interface, and it is potentially a very powerful means to share jenkins job setups across multiple teams and engineers, and even more so if it can work in a way that provides the extensibility and reuse that the groovy language can offer. This means things like class inheritance, interfaces and other OO techniques are desirable and of particular interest to me. Moreover, the flows I'm looking at are inherently quite complex and I would ideally like to generate infra for them that could be used by a number of people/teams - not just copy/pasted. If I go with conservative, I fear I will end up with multiple copies of the same rehashed code for each instance where it is actually used - and that means more places for it to go wrong and maintain. So what would really set the workflow-plugin apart from e.g. a typical multijob setup is the ability to do some of the less "conservative", more "groovy" things Regards, Tom. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27927) Some interface idioms do not work in Groovy CPS
Thomas Dalton
commented on JENKINS-27927
Some interface idioms do not work in Groovy CPS
Ahh.. in which case I apologies for the miscommunication on my part, I actually tried the Java syntax first - I then reduced the problem to simpler forms to post the issue.
Here is what I tried originally:
interface Foo {
String name()
}
class Bar implements Foo {
def String name() {
return "Ronald"
}
}
node {
b = new Bar()
a = b as Foo
echo a.name()
}
This doesn't work either and the same exception Cannot invoke method visit() on null object is thrown.
Yet under a groovy console:
interface Foo {
String name()
}
class Bar implements Foo {
def String name() {
return "Ronald"
}
}
b = new Bar()
a = b as Foo
println a.name()
It works fine. Hence I think it is likely a problem with all uses of interface and why I'm on the lookout for a decent workaround
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27927) Some interface idioms do not work in Groovy CPS
Thomas Dalton commented on JENKINS-27927 Some interface idioms do not work in Groovy CPS If I replace a = b as Foo with Foo a = b It doesn't work either I'm afraid , same exception. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton
commented on JENKINS-27905
Use of stage concurrency only allows 1 thread to be blocked at a time
I understand after some further reading:
https://issues.jenkins-ci.org/browse/JENKINS-25570
https://issues.jenkins-ci.org/browse/JENKINS-27127
That "mutex" like behavior is not really what the concurrency field is all about. It is more for filtering jobs, allowing a certain number to queue up with others effectively thrown away and failed (the secondary issue here is that it seems to hang and leave stale state).
For the benefit of others, after a bit of experimentation I've achieved what I wanted. To run parallel jobs that are similar and for some element of them the same, such that the common parts of their flow have to be serialized. Hopefully the increment below is "atomic" or at least "atomic enough".
The console noise for the waitUntil is a shame though.
class qLock implements Serializable {
int id = 0
List queue = []
def increment() {
return ++id
}
def acquire_id() {
id = this.increment()
this.queue.add(id)
return id
}
def is_ready(int id) {
return (this.queue.indexOf(id) == 0)
}
def release(int id) {
if (this.is_ready(id)) {
this.queue.remove(0)
}
}
}
node {
def sleeps = [ : ]
def ql = new qLock()
for (int i = 0; i 4; i++) {
sleeps["num_${i}"] = { sleep10(ql) }
}
parallel(sleeps)
}
def sleep10 (qLock ql) {
ws {
// try to acquire "lock"
def id = ql.acquire_id()
waitUntil {
// wait until it is my turn
return (ql.is_ready(id))
}
stage name: "Sleeping for 10 secs"
sh "sleep 10"
ql.release(id)
stage name: "Sleep finished"
}
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton
edited a comment on JENKINS-27905
Use of stage concurrency only allows 1 thread to be blocked at a time
I understand after some further reading:
https://issues.jenkins-ci.org/browse/JENKINS-25570
https://issues.jenkins-ci.org/browse/JENKINS-27127
That "mutex" like behavior is not really what the concurrency field is all about. It is more for filtering jobs, allowing a certain number to queue up with others effectively thrown away and failed (the secondary issue here is that it seems to hang and leave stale state).
For the benefit of others, after a bit of experimentation I've achieved what I wanted. To run parallel jobs that are similar and for some element of them the same, such that the common parts of their flow have to be serialized. Hopefully the increment below is "atomic" or at least "atomic enough".
class qLock implements Serializable {
int id = 0
List queue = []
def increment() {
return ++id
}
def acquire_id() {
id = this.increment()
this.queue.add(id)
return id
}
def is_ready(int id) {
return (this.queue.indexOf(id) == 0)
}
def release(int id) {
if (this.is_ready(id)) {
this.queue.remove(0)
}
}
}
node {
def sleeps = [ : ]
def ql = new qLock()
for (int i = 0; i 4; i++) {
sleeps["num_${i}"] = { sleep10(ql) }
}
parallel(sleeps)
}
def sleep10 (qLock ql) {
ws {
// try to acquire "lock"
def id = ql.acquire_id()
// wait until it is my turn
while (!ql.is_ready(id)) {
sleep(1)
}
stage name: "Sleeping for 10 secs"
sh "sleep 10"
ql.release(id)
stage name: "Sleep finished"
}
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) stage concurrency allows 1 thread to be blocked at a time, others fail and hang job
Thomas Dalton updated JENKINS-27905 stage concurrency allows 1 thread to be blocked at a time, others fail and hang job Change By: Thomas Dalton (13/Apr/15 4:39 PM) Summary: Useof stageconcurrency only allows1threadtobeblockedatatime ,othersfailandhangjob Priority: Major Minor This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton
commented on JENKINS-27905
Use of stage concurrency only allows 1 thread to be blocked at a time
Changing the script to following (note the added "exit" stage) seems to fix the problem.
def sleep60 () {
ws {
sh "echo ${env.HOSTNAME}"
stage name: "Sleeping for 60 secs", concurrency: 1
sh "sleep 60"
stage name: "Sleep finished" // exit stage to clear stage concurrency related state
}
}
The error appears to be due to the last stage being the same name as the previous one so effectively we get 2 stages with the same name within the same flow, albeit in parallel closures.
Still not sure whether the reported issue is a real bug, or not. It would be nice not to need to inject stages in this way and for stage related state to be cleared at the end of a closure?
Note also that I had to change the name of the stage because there was a zombie "Sleep for 60 secs" stage still running! The doDelete trick didn't seem to clear it either so that's a secondary (probably more generic?) problem with being able to zap state from failed/hanging jobs.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton edited a comment on JENKINS-27905 Use of stage concurrency only allows 1 thread to be blocked at a time Deleted previous comment because it still doesn't work even with an attempted workaround to add an "exit" stage. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27893) Varargs mishandled in Groovy CPS
Thomas Dalton
commented on JENKINS-27893
Varargs mishandled in Groovy CPS
Thanks Jesse.
For the benefit of others I've tried the following:
node {
fn1("This should only be one string")
fn1("Two", "Strings")
fn2(["is", "This", "Three?"])
fn3(["What", "about", "this?"] as String[])
fn4(["Or", "perhaps", "this?"])
}
def fn1 (String... strs) {
echo "${strs.size()}"
def String s = ""
for (int i = 0; i strs.size(); i++) {
s += "${strs[i]} "
}
echo "$s"
}
def fn2 (strs) {
echo "${strs.size()}"
def String s = ""
for (int i = 0; i strs.size(); i++) {
s += "${strs[i]} "
}
echo "$s"
}
def fn3 (String[] strs) {
echo "${strs.size()}"
def String s = ""
for (int i = 0; i strs.size(); i++) {
s += "${strs[i]} "
}
echo "$s"
}
def fn4 (List strs) {
echo "${strs.size()}"
def String s = ""
for (int i = 0; i strs.size(); i++) {
s += "${strs[i]} "
}
echo "$s"
}
Here were the results:
Running: Allocate node : Start
Running on master in /nobackup/thdalton/jenkins/workspace/Sandbox
Running: Allocate node : Body : Start
Running: Print Message
30
Running: Print Message
T h i s s h o u l d o n l y b e o n e s t r i n g
Running: Print Message
3
Running: Print Message
T w o
Running: Print Message
3
Running: Print Message
is This Three?
Running: Print Message
4
Running: Print Message
W h a t
Running: Print Message
3
Running: Print Message
Or perhaps this?
Running: Allocate node : Body : End
Running: Allocate node : End
Running: End of Workflow
Finished: SUCCESS
I think I prefer the explicit List in fn4() so I shall go with that thanks.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton
updated JENKINS-27905
Use of stage concurrency only allows 1 thread to be blocked at a time
Change By:
Thomas Dalton
(11/Apr/15 11:12 PM)
Description:
Takethefollowingscriptasanexample:{code}node{defsleeps=[:]for(inti=0;i4;i++){sleeps[num_${i}]={sleep60()}}parallel(sleeps)}defsleep60(){ws{stagename:Sleepfor60secs,concurrency:1shsleep60}}{code}Becausethestagesaremarkedwith{{concurrency:1}}
)
,Iwouldexpectthesleepstooccurinseries,butwithall
parallel
tasksperformed.With3,then2,then1taskblockeduntilallarecomplete.Insteadthefirstsleepruns,thesecondblocksonit,buttheothertwomysteriouslyfail,andthisactuallyresultsintheJobhangingindefinitelyandthe2nd
job
sleep
doesntseemto
getto
runeither.{code}StartedbyuseranonymousRunning:Allocatenode:StartRunningonmasterin/mydir/jenkins/workspace/SandboxRunning:Allocatenode:Body:StartRunning:Executesub-workflowsinparallel:Start[num_0]Running:Parallelbranch:num_0[num_1]Running:Parallelbranch:num_1[num_2]Running:Parallelbranch:num_2[num_3]Running:Parallelbranch:num_3[num_0]Running:Allocateworkspace:Start[num_0]Runningin/mydir/jenkins/workspace/Sandbox-2[num_0]Running:Allocateworkspace:Body:Start[num_1]Running:Allocateworkspace:Start[num_1]Runningin/mydir/jenkins/workspace/Sandbox-3[num_1]Running:Allocateworkspace:Body:Start[num_2]Running:Allocateworkspace:Start[num_2]Runningin/mydir/jenkins/workspace/Sandbox-4[num_2]Running:Allocateworkspace:Body:Start[num_3]Running:Allocateworkspace:Start[num_3]Runningin/mydir/jenkins/workspace/Sandbox-5[num_3]Running:Allocateworkspace:Body:Start[num_0]Running:Sleepfor60secs[num_0]EnteringstageSleepfor60secs[num_0]Proceeding[num_0]Running:ShellScript[num_0][Sandbox-2]Runningshellscript[num_1]Running:Sleepfor60secs[num_1]EnteringstageSleepfor60secs[num_1]Waitingforbuilds[7][num_2]Running:Sleepfor60secs[num_2]EnteringstageSleepfor60secsRunning:Allocateworkspace:Body:End[num_3]Running:Sleepfor60secs[num_3]EnteringstageSleepfor60secsRunning:Allocateworkspace:Body:EndRunning:Allocateworkspace:EndRunning:Allocateworkspace:EndRunning:Executesub-workflowsinparallel:Body:EndRunning:Executesub-workflowsinparallel:Body:End[num_0]+sleep60Running:Allocateworkspace:Body:EndRunning:Allocateworkspace:EndRunning:Executesub-workflowsinparallel:Body:End{code}Iassumethisisjustabugratherthanmymisunderstandingoftheuseof{{concurrency}}butImhappytobecorrected!
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-27905) Use of stage concurrency only allows 1 thread to be blocked at a time
Thomas Dalton
created JENKINS-27905
Use of stage concurrency only allows 1 thread to be blocked at a time
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-plugin
Created:
11/Apr/15 10:56 PM
Description:
Take the following script as an example:
node {
def sleeps = [ : ]
for (int i = 0; i 4; i++) {
sleeps["num_${i}"] = { sleep60() }
}
parallel(sleeps)
}
def sleep60 () {
ws {
stage name: "Sleep for 60 secs", concurrency: 1
sh "sleep 60"
}
}
Because the stages are marked with concurrency: 1), I would expect the sleeps to occur in series, but with all parallel tasks performed. With 3, then 2, then 1 task blocked until all are complete.
Instead the first sleep runs, the second blocks on it, but the other two mysteriously "fail", and this actually results in the Job hanging indefinitely and the 2nd job doesn't seem to run either.
Started by user anonymous
Running: Allocate node : Start
Running on master in /mydir/jenkins/workspace/Sandbox
Running: Allocate node : Body : Start
Running: Execute sub-workflows in parallel : Start
[num_0] Running: Parallel branch: num_0
[num_1] Running: Parallel branch: num_1
[num_2] Running: Parallel branch: num_2
[num_3] Running: Parallel branch: num_3
[num_0] Running: Allocate workspace : Start
[num_0] Running in /mydir/jenkins/workspace/Sandbox-2
[num_0] Running: Allocate workspace : Body : Start
[num_1] Running: Allocate workspace : Start
[num_1] Running in /mydir/jenkins/workspace/Sandbox-3
[num_1] Running: Allocate workspace : Body : Start
[num_2] Running: Allocate workspace : Start
[num_2] Running in /mydir/jenkins/workspace/Sandbox-4
[num_2] Running: Allocate workspace : Body : Start
[num_3] Running: Allocate workspace : Start
[num_3] Running in /mydir/jenkins/workspace/Sandbox-5
[num_3] Running: Allocate workspace : Body : Start
[num_0] Running: Sleep for 60 secs
[num_0] Entering stage Sleep for 60 secs
[num_0] Proceeding
[num_0] Running: Shell Script
[num_0] [Sandbox-2] Running shell script
[num_1] Running: Sleep for 60 secs
[num_1] Entering stage Sleep for 60 secs
[num_1] Waiting for builds [7]
[num_2] Running: Sleep for 60 secs
[num_2] Entering stage Sleep for 60 secs
Running: Allocate workspace : Body : End
[num_3] Running: Sleep for 60 secs
[num_3] Entering stage Sleep for 60 secs
Running: Allocate workspace : Body : End
Running: Allocate workspace : End
Running: Allocate workspace : End
Running: Execute sub-workflows in parallel : Body : End
Running: Execute sub-workflows in parallel : Body : End
[num_0] + sleep 60
Running: Allocate workspace : Body : End
Running: Allocate workspace : End
Running: Execute sub-workflows in parallel : Body : End
I assume this is just a bug rather than my misunderstanding of the use of concurrency but I'm happy to be corrected!
Environment:
Jenkins 1.606
Workflow 1.5
Project:
Jenkins
Priority:
Major
Reporter:
Thomas Dalton
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
