[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

['jerrywil...@gmail.com (JIRA)' via Jenkins Issues]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Yes, i opened issue in February asking for release here:  https://github.com/jenkinsci/concurrent-step-plugin/issues/5  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.24396.1589161800963%40Atlassian.JIRA.

[JIRA] (JENKINS-61462) Jenkinsfile parameter default values not evaluted on first-run when read from scm

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61462  
 
 
  Jenkinsfile parameter default values not evaluted on first-run when read from scm   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2020-03-12 16:50  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 As of... CloudBees Jenkins Distribution 2.176.2.3-rolling To reproduce 
 
Create a jenkinsfile on SCM 
Give it a parameter of any type (for example, a string named "greeting") 
Give it some default value of "Hello World" 
Add a step to echo the value of "greeting" 
Add a new jenkins job: type=pipeline 
Choose "pipeline script from scm" 
Point to the Jenkinsfile you added in step 1 
Click "build" button 
 
Of note, "Build with parameters isn't an option because Jenkins doesn't know that the job has a parameter when it's added this way". I believe this is the root of the issue. 
  
 So, the first run of the job should print "null" rather than "Hello World" because using the "build" button seems to set all the parameters to "null" instead of using their default values.  After the first run, the job will have a "Build with parameters" button, so the issue will never occur again. I'm not sure what a sensible approach is to 

[JIRA] (JENKINS-61462) Jenkinsfile parameter default values not evaluted on first-run when read from scm

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61462  
 
 
  Jenkinsfile parameter default values not evaluted on first-run when read from scm   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2020-03-12 16:50  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 As of... CloudBees Jenkins Distribution 2.176.2.3-rolling To reproduce 
 
Create a jenkinsfile on SCM 
Give it a parameter of any type (for example, a string named "greeting") 
Give it some default value of "Hello World" 
Add a step to echo the value of "greeting" 
Add a new jenkins job: type=pipeline 
Choose "pipeline script from scm" 
Point to the Jenkinsfile you added in step 1 
Click "build" button 
 
Of note, "Build with parameters isn't an option because Jenkins doesn't know that the job has a parameter when it's added this way". I believe this is the root of the issue. 
  
 So, the first run of the job should print "null" rather than "Hello World" because using the "build" button seems to set all the parameters to "null" instead of using their default values.  After the first run, the job will have a "Build with parameters" button, so the issue will never occur again. I'm not sure what a sensible approach is to 

[JIRA] (JENKINS-61327) Feature : Pipeline-Defined Hooks for General Jenkins Events

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61327  
 
 
  Feature : Pipeline-Defined Hooks for General Jenkins Events   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2020-03-04 17:41  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 Preface This is a major feature with potentially prohibitive core engineering implications, but I am unable to determine the scope of those implications myself. If you are a core jenkins contributor and you see any merit in this feature request, please comment about the feasibility. Also of note, I'm specifically requesting this as a "core feature" because I am not confident it's possible (or a good idea) to implement it as a Jenkins plugin. I could be wrong about this, in which case a valid vote might be "this could/should be implemented as a plugin". If it's clearly unsupportable in any context, and/or nobody feels it should move forward, this request should be closed sooner rather than later. All the more reason I request feedback from core team. Synopsis There are many native Jenkins events related to a job which occur frequently but are not part of the jobs "execution" logic, so they are not natively accessible or actionable for users without a custom plugin for the dedicated purpose. This is because "pipelines" are executed from the known list of "trigger" event types, which is a small subset of "jenkins events". Thus, "job execution" is limited to the context of "trigger events". In theory, a plugin could be written to turn any particular "jenkins event" into a new custom "trigger" type.  However, plugins are overkill for many enterprise needs, which are often one-off, short term, or just very custom. Also, the scope of creating/supporting/maintaining a Jenkins plugin is prohibitive for many non-expert Jenkins users/administrators, many of whom are not Java developers. Much like Jenkins Shared Libraries provide an easier entrypoint for adding custom programming facilities to Jenkins jobs when compared 

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Thanks for testing this out.  We might be able to give it a try if the author releases an official non-beta version in the near future.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.5170.1583341740963%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 No, it looks really good, unfortunately it says "can only be used in pipeline script" which seems to indicate declarative pipeline cannot use it.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.6264.1582642320948%40Atlassian.JIRA.

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. Another way (this one focused on feasibility) might be to add a new function:  {code:java}currentJob.hide(Closure c){code} Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly": {code:java}currentJob.hide(Closure c) (not transitive)currentJob.hideAll(Closure c) (transitive)currentJob.show(Closure c) (overrides hideAll) {code} I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean". Of note, this suggestion would also solve one of the problems discussed in this issue: https://issues.jenkins-ci.org/browse/JENKINS-44085Wherein the wait() block renders terribly as seen in the second screenshot attached (jenkins-parallel-waits.jpg)  Edit: If it were technically possible/feasible for Jenkins to have conditional behavior based on Java annotations in Jenkins Shared library code, then that would be the "most desirable" and ergonomic way to tune a cross-cutting-concern behavior like rendering behavior.  I notice that @Grab and @NonCPS are annotations that are supported in Jenkins Shared Library code... so this seems feasible.  In that case IF it's possible ,  I  then the implementation  would  probably largely occur 

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. Another way (this one focused on feasibility) might be to add a new function:  {code:java}currentJob.hide(Closure c){code} Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly": {code:java}currentJob.hide(Closure c) (not transitive)currentJob.hideAll(Closure c) (transitive)currentJob.show(Closure c) (overrides hideAll) {code} I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean". Of note, this suggestion would also solve one of the problems discussed in this issue: https://issues.jenkins-ci.org/browse/JENKINS-44085Wherein the wait() block renders terribly as seen in the second screenshot attached (jenkins-parallel-waits.jpg)  Edit: If it were technically possible/feasible for Jenkins to have conditional behavior based on Java annotations in Jenkins Shared library code, then that would be the "most desirable" and ergonomic way to tune a cross-cutting-concern behavior like rendering behavior.   Of note, if it were possible, this actually would be interesting for other purposes as well, but    I  imagine it's likely  notice  that  there's some technical reason that  @Grab and @NonCPS are  annotations  that are supported  in  JSL  Jenkins Shared Library  code  are just "impossible" . .. so this seems 

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. Another way (this one focused on feasibility) might be to add a new function:  {code:java}currentJob.hide(Closure c){code} Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly": {code:java}currentJob.hide(Closure c) (not transitive)currentJob.hideAll(Closure c) (transitive)currentJob.show(Closure c) (overrides hideAll) {code} I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean". Of note, this suggestion would also solve one of the problems discussed in this issue: https://issues.jenkins-ci.org/browse/JENKINS-44085Wherein the wait() block renders terribly as seen in the second screenshot attached (jenkins-parallel-waits.jpg)   Edit: If it were technically possible/feasible for Jenkins to have conditional behavior based on Java annotations in Jenkins Shared library code, then that would be the "most desirable" and ergonomic way to tune a cross-cutting-concern behavior like rendering behavior.  Of note, if it were possible, this actually would be interesting for other purposes as well, but I imagine it's likely that there's some technical reason that annotations in JSL code are just "impossible".  
 

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. Another way (this one focused on feasibility) might be to add a new function:  {code:java}currentJob.hide(Closure c){code} Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly": {code:java}currentJob.hide(Closure c) (not transitive)currentJob.hideAll(Closure c) (transitive)currentJob.show(Closure c) (overrides hideAll) {code} I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean". Of note, this suggestion would also solve one of the problems discussed in this issue: https://issues.jenkins-ci.org/browse/JENKINS-44085Wherein the wait()  block renders terribly as seen in the second screenshot attached (jenkins-parallel-waits.jpg)      
 

  
 
 
 
 

 
 
 

   

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Attachment: 
 jenkins-parallel-waits.jpg  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204449.1580916277000.1861.1580917020237%40Atlassian.JIRA.

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. Another way (this one focused on feasibility) might be to add a new function:  {code:java}currentJob.hide(Closure c){code} Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly": {code:java}currentJob.hide(Closure c) (not transitive)currentJob.hideAll(Closure c) (transitive)currentJob.show(Closure c) (overrides hideAll) {code} I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean".  Of note, this suggestion would also solve one of the problems discussed in this issue: https://issues.jenkins-ci.org/browse/JENKINS-44085Wherein the wait()   
 

  
 
 
 
 

 
 
 

 
  

[JIRA] (JENKINS-60981) FlowGraphTable view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  FlowGraphTable view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Summary: 
 Pipeline steps FlowGraphTable  view scales poorly for complex nested functions  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204449.1580916277000.1855.1580916360122%40Atlassian.JIRA.

[JIRA] (JENKINS-60981) Pipeline steps view scales poorly for complex nested functions

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60981  
 
 
  Pipeline steps view scales poorly for complex nested functions   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 pipeline_steps_view.jpg  
 
 
Components: 
 workflow-job-plugin  
 
 
Created: 
 2020-02-05 15:24  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.   Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases. Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances.  I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below. One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad.  Another way (this one focused on feasibility) might be to add a new function:    

 

currentJob.hide(Closure c) 
  

[JIRA] (JENKINS-60980) pipeline-stage-view slows as stage count increases, becomes unusable

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60980  
 
 
  pipeline-stage-view slows as stage count increases, becomes unusable   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Issue Type: 
 Bug Improvement  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204448.1580914513000.1854.1580916300482%40Atlassian.JIRA.

[JIRA] (JENKINS-60980) pipeline-stage-view slows as stage count increases, becomes unusable

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60980  
 
 
  pipeline-stage-view slows as stage count increases, becomes unusable   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Component/s: 
 pipeline-stage-view-plugin  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204448.1580914513000.1838.1580914800096%40Atlassian.JIRA.

[JIRA] (JENKINS-60980) pipeline-stage-view slows as stage count increases, becomes unusable

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60980  
 
 
  pipeline-stage-view slows as stage count increases, becomes unusable   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Summary: 
 Job status screen pipeline-stage-view  slows as stage count increases, becomes unusable  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204448.1580914513000.1837.1580914740126%40Atlassian.JIRA.

[JIRA] (JENKINS-60980) Job status screen slows as stage count increases, becomes unusable

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60980  
 
 
  Job status screen slows as stage count increases, becomes unusable   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 core  
 
 
Created: 
 2020-02-05 14:55  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 We have functional jobs which enumerate lists and spawn parallel stages for each item in the list.  We have several which run 100+ tests.   The load speed and page width of the built-in job status/summary screen scales really poorly with the number of stages.  The page width is ugly after just 10 stages, and the performance becomes a problem around 50 (depending on the resource of the machine). Over 300, it can become unusable and can crash browser, especially when multiple tabs are open. The blue-ocean plugin is certainly better, but it's still a problem with the official jenkins UI, so i'm reporting it. From a UI perspective, I'm sure there are a number of simple ways to resolve these two issues without an overhaul of the whole page, and without breaking backward compatibility.  I will suggest one, it may be a terrible one, but my org really wants these problems to be fixed. Add a section in Manage Jenkins somewhere for global GUI setting defaults.  I'm surprised nothing like this exists already.  Add "max stages" setting in that section.  Have the job status/summary page check that setting, and only load that many stages while rendering the page.  Add a "show all stages" button to that page when rendering pages which exceeded this max.  Also of note, I am going to open another ticket about default view rendering of the pipeline_steps view which also scales very poorly when nesting many jenkins functions. I think this could also benefit from having a number of relevant settings in a new "global gui setting defaults" section.  
 

  
 
 

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Thanks for the effort!  i just updated my last post with the actual calling code rather than the thing with the agent labels.  Indeed, this semaphore-like strategy is another form of the previously posted suggestions with a limited number of named queues, where jobs get assigned to queues at the start and which suffers from the limitations/disadvantages you mentioned.  For our case, it's a lot less desirable than the current queuing strategy, if only the wait step didn't have the verbosity problem.  I'll continue to look for suggestions on making the current strategy work, and working around that problem.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.10243.1580576220834%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I don't understand this most recent suggestion. I've never worked with semaphores, proper or otherwise. The drawbacks already sound significant and prohibitive.[~teilo] we're still stuck on this.Our current implementation adds 25%-75% to the runtime of a parallel job in our bigger jobs, presumably because of the CPU monopolization that you mentioned. Right now, we simply can't use it, and so we still don't have a throttling mechanism for our case.If waitUntil() could be changed to be a single step as you mentioned, that could solve it for us with less custom code, that would be desirable. I'd be surprised if anyone would disagree with the premise of that request. Where could i file the feature request for that step? I don't know what plugin it would be part of.In the meantime, do you have any other suggestions on how to fix our current implementation so that it doesn't kill performance?{code:java}static def parallelLimitedBranches(CpsScript currentJob,List items,Integer maxConcurrentBranches,Boolean failFast = false,Closure body) {def branches = [:]Deque latch = new LinkedBlockingDeque(maxConcurrentBranches)maxConcurrentBranches.times {latch.offer("$it")}items.each {branches["${it}"] = {def queueSlot = nullwhile (true) {queueSlot = latch.pollFirst();if (queueSlot != null) { break;}}try {body(it)}finally {latch.offer(queueSlot)}}}currentJob.parallel(branches)}{code}With calling code in the form of:{code:java} List agents = Jenkins.instance.computers.collect { Computer computer -> computer.getName()}maxParallelBranches = 10 parallelLimitedBranches(currentJob,  agents  uuids , maxParallelBranches, false) { String  agent  uuid  ->currentJob.stage( agent "${uuid.trim( ) }")  {currentJob.node( agent parallelAgentLabel ) {echo "somevalue"}} } {code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 
   

[JIRA] (JENKINS-60938) Solve problem of too many .groovy files in job directories

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-60938  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Solve problem of too many .groovy files in job directories   
 

  
 
 
 
 

 
 Just did a recursive walk of our jobs directory.  There are 5,597,016 groovy files.    Our JSL has about 60 groovy files.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204335.1580478194000.9587.1580491140047%40Atlassian.JIRA.

[JIRA] (JENKINS-60938) Solve problem of too many .groovy files in job directories

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-60938  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Solve problem of too many .groovy files in job directories   
 

  
 
 
 
 

 
 Just did a recursive walk of our jobs directory.  There are 5,597,016 groovy files.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204335.1580478194000.9586.1580491020063%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I don't understand this most recent suggestion. I've never worked with semaphores, proper or otherwise. The drawbacks already sound significant and prohibitive. James Nord we're still stuck on this. Our current implementation adds 25%-75% to the runtime of a parallel job in our bigger jobs, presumably because of the CPU monopolization that you mentioned. Right now, we simply can't use it, and so we still don't have a throttling mechanism for our case. If waitUntil() could be changed to be a single step as you mentioned, that could solve it for us with less custom code, that would be desirable. I'd be surprised if anyone would disagree with the premise of that request. Where could i file the feature request for that step? I don't know what plugin it would be part of. In the meantime, do you have any other suggestions on how to fix our current implementation so that it doesn't kill performance? 

 

static def parallelLimitedBranches(
CpsScript currentJob,
List items,
Integer maxConcurrentBranches,
Boolean failFast = false,
Closure body) {

def branches = [:]
Deque latch = new LinkedBlockingDeque(maxConcurrentBranches)
maxConcurrentBranches.times {
latch.offer("$it")
}

items.each {
branches["${it}"] = {
def queueSlot = null
while (true) {
queueSlot = latch.pollFirst();
if (queueSlot != null) {
break;
}
}
try {
body(it)
}
finally {
latch.offer(queueSlot)
}
}
}

currentJob.parallel(branches)
}
 

 With calling code in the form of: 

 

List agents = Jenkins.instance.computers.collect { Computer computer -> computer.getName()}
maxParallelBranches = 10
parallelLimitedBranches(currentJob, agents, maxParallelBranches, false) { String agent ->
currentJob.stage(agent) {
currentJob.node(agent) {
echo "somevalue"
}
}
}
 

  
 

  
 
 
 
 

 
 
 

 
 
   

[JIRA] (JENKINS-60938) Solve problem of too many .groovy files in job directories

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60938  
 
 
  Solve problem of too many .groovy files in job directories   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 workflow-cps-global-lib-plugin  
 
 
Created: 
 2020-01-31 13:43  
 
 
Labels: 
 plugin pipeline jenkins  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 When using Jenkins shared libraries (JSLs), by default, all the .groovy files are stored in the job directory along with the rest of the logs and data. The files are small, usually smaller than logs. However, recently, we've received warnings that the volume with the job directories is low on free INODES, which means "too many files". So, file count actually is significant at scale. We want to keep our job logs as long as possible, but care much less about keeping the .groovy files. Deleting only the .groovy files would enable us to keep roughly 100 times the number of logs. Currently, buildDiscarder property gives us a per-job cleanup policy which is good. However, currently it provides no granularity over the files in the directory which is understandable,  This feature request is to suggest looking at the many options available for solving such a problem, and hopefully finding one which is easy to implement.  For example: 
 
enhance build buildDiscarder property with special handling for groovy files 
create similar-but-different property called "buildPostProcessor" (generic) 
create similar-but-different property called "discardGroovyFiles" (specific) 

[JIRA] (JENKINS-60063) Add Signature to withEnv to take Map

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60063  
 
 
  Add Signature to withEnv to take Map   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 workflow-basic-steps-plugin  
 
 
Created: 
 2019-11-05 15:51  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 We have this utility function in our Jenkins Shared Library: 

 

static List convertMapToJenkinsEnv(Map srcEnv) {
return srcEnv.collect { "${it.key}=${it.value}"}
} 

 It seems obvious that this could be an alternative signature to the current basic built-in function: 

 

withEnv
 

 For us, it's far more ergonomic to work with and compose maps in our Shared Library and scripted pipelines, taking advantage of it's well-defined characteristics surrounding unique keys etc.  It seems as trivial as it could be to implement this.   
 

  
 
 
 
 

 
 
 

  

[JIRA] (JENKINS-60063) Add Signature to withEnv to take Map

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60063  
 
 
  Add Signature to withEnv to take Map   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 We have this utility function in our Jenkins Shared Library:{code:java}static List convertMapToJenkinsEnv(Map srcEnv) {return srcEnv.collect { "${it.key}=${it.value}"}}{code}It seems obvious that this could be an alternative signature  and implementation  to the current basic built-in function:{code:java}withEnv{code}For us, it's far more ergonomic to work with and compose maps in our Shared Library and scripted pipelines, taking advantage of it's well-defined characteristics surrounding unique keys etc.  It seems as trivial as it could be to implement this.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-59893) bat calls hang in Windows Docker container in declarative pipeline script

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-59893  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: bat calls hang in Windows Docker container in declarative pipeline script   
 

  
 
 
 
 

 
 This matrix is how I learned about it.  It might be helpful to you: https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202638.1571768371000.8634.1572898800155%40Atlassian.JIRA.

[JIRA] (JENKINS-59893) bat calls hang in Windows Docker container in declarative pipeline script

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-59893  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: bat calls hang in Windows Docker container in declarative pipeline script   
 

  
 
 
 
 

 
 I think you either need to be on a newer version of docker, or you need to enable experimental features.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202638.1571768371000.8576.1572898203531%40Atlassian.JIRA.

[JIRA] (JENKINS-59893) bat calls hang in Windows Docker container in declarative pipeline script

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-59893  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: bat calls hang in Windows Docker container in declarative pipeline script   
 

  
 
 
 
 

 
 I  don't use quotes, but i don't  think  that's the issue.  I think  you either need to be on a newer version of docker, or you need to enable experimental features.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202638.1571768371000.8584.1572898203819%40Atlassian.JIRA.

[JIRA] (JENKINS-59893) bat calls hang in Windows Docker container in declarative pipeline script

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-59893  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: bat calls hang in Windows Docker container in declarative pipeline script   
 

  
 
 
 
 

 
 If you pass `–isolation=hyperv` you can run images based on any windows kernel, regardless of what kernel the host is on.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202638.1571768371000.7815.1572798600276%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 This naive code seems to work fine, can you think of any issue with using it?  

 

while(true) {
 thing = latch.pollFirst();
 if (thing != null){
 break;
 }
 } 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.5761.1567520220971%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I tried doing the following replacement and the first batch of branches  just hang after "sleeping  run  for  5 seconds". They don't  15 minutes and then  print goodbye.    All the other branches fail with stacktraces with the stacktraces below.  Having never worked with the blocking queue api, i don't have a good guess as to what the problem is:  +*Replaced this:*+   {code:java} def thing = null waitUntil{   thing = latch.pollFirst();   return thing != null; }{code} +*With this:*+{code:java} def thing = latch. take(){code} what should it be?  {code:java}Also:   java.lang.InterruptedException  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2014)  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2048)  at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)  at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:680)  at sun.reflect.GeneratedMethodAccessor5683.invoke(Unknown Source)Also:   java.lang.InterruptedException  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2014)  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2048)  at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)  at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:680)  at sun.reflect.GeneratedMethodAccessor5683.invoke(Unknown Source){code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





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

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I tried doing the following replacement and the first batch of branches just hang after "sleeping for 5 seconds". They don't print goodbye.   Having never worked with the blocking queue api, i don't have a good guess as to what the problem is:  +*Replaced this:*+ waitUntil    { code:java}  waitUntil{   thing = latch.pollFirst(); return thing != null;  }  {code  }     +*With this:*+ {code:java} take() {code} what should it be?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.5113.1567465621022%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I tried doing the following replacement and the first batch of branches just hang after "sleeping for 5 seconds". They don't print goodbye.   Having never worked with the blocking queue api, i don't have a good guess as to what the problem is:    Replaced this: waitUntil  { thing = latch.pollFirst(); return thing != null; } With this: take()  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.5037.1567454700908%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 yes, it is.  blue ocean is nice, but this is the default UI/UX and it's what most users in my company still look at out of habit.  Is there no native java or groovy "wait" function which isn't a pipeline function?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4936.1567452301622%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Apologies, I've just implemented yours and I did indeed misunderstand something fundamental to your approach.  Even though the Map of closures is Final, inserting new key/value pairs at runtime does seem to create new stages on the fly .  I read yours and then read [~nitschsb]'s example right after.  I believed his was just a more polished implementation of the same technique.  In particular, his avoided the use of waitUntil.  After running your implementation, I do see that waitUntil is a bit of a problem from the UX point of view.  Do you think there's anything we can do to avoid this?  With really long jobs, this isn't really going to be manageable/acceptable to have all these waits.   If we can avoid this, it should be a workable solution.   !jenkins-parallel-waits.jpg|thumbnail!     
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4766.1567451460942%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Apologies, I've just implemented yours and I did indeed misunderstand something fundamental to your approach.  Even though the Map of closures is Final, inserting new key/value pairs at runtime does seem to create new stages on the fly .  I read yours and then read [~nitschsb]'s example right after.  I believed his was just a more polished implementation of the same technique.  In particular, his avoided the use of waitUntil.  After running your implementation, I do see that waitUntil is a bit of a problem from the UX point of view.  Do you think there's anything we can do to avoid this?  With really long jobs, this isn't really going to be manageable/acceptable to have all these waits.   !image-2019-09-02-15-04-30-193.png|thumbnail!   !image-2019-09-02-15-04-30-193.png!       
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4678.1567451283535%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-44085  
 
 
  have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Attachment: 
 jenkins-parallel-waits.jpg  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4721.1567451284103%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Apologies, I've just implemented yours and I did indeed misunderstand something fundamental to your approach.  Even though the Map of closures is Final, inserting new key/value pairs at runtime does seem to create new stages on the fly .  I read yours and then read [~nitschsb]'s example right after.  I believed his was just a more polished implementation of the same technique.  In particular, his avoided the use of waitUntil.  After running your implementation, I do see that waitUntil is a bit of a problem from the UX point of view.  Do you think there's anything we can do to avoid this?  With really long jobs, this isn't really going to be manageable/acceptable to have all these waits.    !jenkins-parallel-waits.jpg|thumbnail!        
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4723.1567451284130%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-44085  
 
 
  have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Attachment: 
 image-2019-09-02-15-04-30-193.png  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4594.1567451221270%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 Apologies, I've just implemented yours and I did indeed misunderstand something fundamental to your approach.  Even though the Map of closures is Final, inserting new key/value pairs at runtime does seem to create new stages on the fly .  I read yours and then read Mario Nitsch's example right after.  I believed his was just a more polished implementation of the same technique.  In particular, his avoided the use of waitUntil.    After running your implementation, I do see that waitUntil is a bit of a problem from the UX point of view.  Do you think there's anything we can do to avoid this?  With really long jobs, this isn't really going to be manageable/acceptable to have all these waits.               
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4551.1567451160843%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-44085  
 
 
  have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Attachment: 
 image-2019-09-02-15-04-30-193.png  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181710.1494001199000.4508.1567451102277%40Atlassian.JIRA.

[JIRA] (JENKINS-44085) have a simple way to limit the number of parallel branches that run concurrently

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-44085  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: have a simple way to limit the number of parallel branches that run concurrently   
 

  
 
 
 
 

 
 I had exactly the same need, and I think this feature request has a lot of merit and is going to keep coming up for advanced use cases.  Unfortunately, I think implementing the feature as-requested is infeasible, so I make a recommendation here for an alternative approach that might actually be actionable for the Jenkins team.  Workarounds:  I tried implementing the workarounds proposed here.  They are clever, but fundamentally subvert the desired structure of the job logs and UI.  They create a number of numbered stages corresponding to the max number of parallel tasks desired by the user, and then use those as "quasi-executors" with LinkedBlockingQueue scheduling the actual tasks.  Therefor, it does not produce "1-stage-per-task" in the log or the UI.  That is what we get if we loop over a list and dynamically create a stage for each item.  We just want the stages to be run in parallel and throttled.   We could almost implement the desired behavior in a pipeline today in a relatively simple and intuitive way  We could use a very similar LinkedBlockingQueue strategy and gradually spawn stages inside the parallel block as we dequeue through our queue. Almost.  Fundamental Problem: The implementation of the parallel block is such that all the stages executed inside the parallel block must be passed to the ParallelStep constructor (and thus known at the start of the block).  The Map of all closures to be executed is marked final, so new stages cannot be dynamically started inside the parallel block once it has been constructed no matter what. https://github.com/jenkinsci/pipeline-plugin/blob/workflow-1.15/cps/src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java#L47 The current ParallelStep code is part of the very fundamental pipeline-plugin, and the code required to implement the desired behavior is going to require a significant amount of complexity.  Thus, it seems unlikely that anyone can safely or comfortably modify this plugin in such a way that supports this feature request.  This is likely why Jenkins team has not touched this ticket since it was opened in 2017, and why the plugin itself hasn't changed since 2016.  Suggestions: Give us a new ParallelDynamic step to expose Jenkins parallel capabilities for more general use.  Make it virtually identical to Parallel in most ways, but supports adding closures to the map dynamically at runtime.  This approach is flexible, as it would empower users implement their own scheduling strategies outside parallel block.  In theory, adding a single function to the API such as "parallel.dynamicStage(newStage)" would likely be enough to satisfy many use cases.  This minimalistic approach avoids getting into the somewhat subjective design space about how general-purpose throttling should be implemented at the start.  Later, someone could then choose to provide a default throttled implementation on top if that is still desired, but I don't think it's necessary at first.   
 

  
 
 
 
 

 
 
 

  

[JIRA] (JENKINS-57648) Add New DependencyGraph API's for declarative pipelines

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57648  
 
 
  Add New DependencyGraph API's for declarative pipelines   
 

  
 
 
 
 

 
Issue Type: 
  Story  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 core  
 
 
Created: 
 2019-05-23 17:36  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 Overview Jenkins core never received the critical features or capabilities for plugin writers to do anything related to the job dependency graph (upstreams/downstreams) in the context of Declarative Pipelines.  Currently, the graph is near impossible to work with for plugin authors, and thus none of the plugins dealing with dependency graphs support declarative pipelines, even though they have now existed for several years.  So, a great deal of critical Jenkins functionality is effectively unavailable for users of declarative pipelines including:  
 
Visualizing the Dependency Graph 
FanOut and FanIn of Jobs 
Blocking Execution based on Upstream/Downstream Status 
Evaluating any condition based on a dependency 
 Organizations which require these capabilities simply can't use declarative pipelines.  Here are just a few other issues relating to dependency graph needs: https://issues.jenkins-ci.org/browse/JENKINS-29913 https://issues.jenkins-ci.org/browse/JENKINS-19728 https://issues.jenkins-ci.org/browse/JENKINS-33577 https://issues.jenkins-ci.org/browse/JENKINS-19727 Background Prior to pipelines, there were extensive, advanced, and widely used plugins related to the dependency graph. These types of plugins were vital to using Jenkins in many non-trivial codebases, and are no-less vital to using Declarative Pipelines. These were empowered by the extremely robust and extensive 

[JIRA] (JENKINS-46124) EnvStep convert map to list

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-46124  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: EnvStep convert map to list   
 

  
 
 
 
 

 
 Did anyone ever file a separate issue to create an overload of withEnv which takes a Map?  Indeed, the overload to pass a Map would be convenient for us as well.  I assumed the reason for the current signature was that Groovy's underlying string helper function "execute()" takes a String[] called envp for environment variables, so withEnv was designed in such a way that the env vars could just be passed through without a type conversion.  Otherwise, I can't imagine why it was designed this way.  Of note, it seems the GDSL file currently says it takes a Map, which appears to be simply incorrect.    

 

method(name: 'withEnv', type: 'Object', params: [overrides:Map, body:'Closure'], doc: 'Set environment variables') 

      
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-56758) Varargs not supported in shared pipeline method signatures

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-56758  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Varargs not supported in shared pipeline method signatures   
 

  
 
 
 
 

 
 I just spent a few hours figuring out the same thing.  This one was tricky to diagnose.  Of note, I found a different workaround.  You can keep the varargs signature if the caller forces the args to be an ArrayList with brackets. So, in your example, caller can do this: {code:java}testUtils("${s}", ["${t1}", "${t2}"]){code} Or caller can just create a regular string.  Both of the workarounds have undesired side-effects IMO. Hope it get fixed properly.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-56758) Varargs not supported in shared pipeline method signatures

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-56758  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Varargs not supported in shared pipeline method signatures   
 

  
 
 
 
 

 
 I just spent a few hours figuring out the same thing.  This one was tricky to diagnose.  Of note, I found a different workaround.  You can keep the varargs signature if the caller forces the args to be an ArrayList with brackets.  So, in your example, caller can do this:  

 

testUtils("${s}", ["${t1}", "${t2}"]) 

 Both of the workarounds have undesired side-effects IMO. Hope it get fixed properly.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-7004) cause not working in parameterized projects

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-7004  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: cause not working in parameterized projects   
 

  
 
 
 
 

 
 We've done some testing and reviewed the commits, and the Cause field does not seem to be fully supported on parameterized builds.   As victor maslov has said, the `cause` field does not work at all when using http auth via header or URL.  The job MUST have a `token` assigned, and as Adam Monsen has said, it MUST come before the `cause` parameter.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-7004) cause not working in parameterized projects

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-7004  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: cause not working in parameterized projects   
 

  
 
 
 
 

 
 We've done some testing and reviewed the commits, and the Cause field does not seem to be fully supported on parameterized builds.   As [~nakilon] has said, the `cause` field does not work at all when using http auth via header or URL.  The job MUST have a `token` assigned, and as [~amonsen] has said, it MUST come before the `cause` parameter. I suggest reopening this ticket.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 I have some new information that might be relevant to isolating the problem. I moved the pipline out of jenkinsfile and into the GUI. The duplicates in the changelog have gone away.  Thus, the recipe for at least one problem is simple:  
 
Pipeline from SCM 
SVN being the SCM used for this 
Multiple Stages? 
 Unfortunately, we can't currently find a workaround here without more help.  It seems that when not using "pipeline script from SCM", the stages all run in different subdirectories rather than the directory the "checkout" stage ran in.  For some reason, the first stage after "checkout" runs in the same directory, but the others choose different directories.  our existing scripts all count on the files being there from a checkout.    Also, obviously, we want to use "pipeline script from scm", and it's really crazy if we cant.  Thanks again for any feedback.     
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Also of note, I've discovered that we'll never really be able to use:  

 

skip_default_checkout() 

 as any part of a workaround because then we don't get 

 

SVN_REVISION_1
and
SVN_REPOSITORY_URL 

 environment variable which we require.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Is there any other report of a similar issue? Are we the only ones having this problem with parallel jobs? Maybe few people still use SVN Plugin?   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Andrew Bayer : regarding "skip default checkout" and the related "checkout to subdirectory".   How do these options relate to "Pipelines script from SCM?" I currently have removed the checkout stage/step in all our jenkinsfiles, thus the only SVN "checkout" and polling are the ones relating to "Pipeline script from SCM".  Do these two options have any affect on the Pipeline script from scm behavior?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 is there any additional logging i can turn on to try to identify the root cause of this issue?  Also, if we have 3 or 4 commits in a row before, we have 1 job for each commit kick off basically at the same time. They all share a single source directory, so I wonder if there's not some contention/conflict between each of those build threads.   Also, I want to make sure you have taken notice of my previous point about duplicate changes messages, so i attached a screenshot.  1 commit, 5 identical changes are listed (the number of times it appears is equal to number of stages).  Also, currently we have parallel builds disabled and it's still showing these duplicates.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-53140  
 
 
  Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 
 
Attachment: 
 Screenshot-of-jenkins-svn-duplicate-changes.png  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 I managed to get it set , restored the parallel builds, and they failed again immediately,  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Per the suggestion, at the top level of the Jenkinsfile we added the following: 

 

skipDefaultCheckout(true) 

 Unfortunately, it caused a surprising issue that we don't understand.  You can see the following lines in our steps: 

 

python build.py 

  build.py runs a docker container passing the SVN credentials via -e.  The docker container runs another python script which does an SVN checkout all of which works as desired. After adding skipDefaultCheckout(true), the SVN checkout inside the docker containers failed.  The most likely candidate seems to be that it somehow broke the passing of the SVN_CREDENTIALS environment variables to the container.    Rather than troubleshoot that at yesterday, i tried putting skipDefaultCheckout(true) in the checkout step. Unfortunately, that did not fix the issue.   If you have ideas about why skipDefaultCheckout(true) might have broken the environment variable, maybe we can work around it.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





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

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Here's the log from one poll cycle.  This demonstrates the fact that Jenkins polls one of the SCM URL's once for each stage that exists which is curious.  It polls the other SCM URL only once which seems correct:  This "Bug" would seem to make more sense to me if it was doing multiple polls on the URL defined in the Jenkinsfile, but it's not.  Multiple polls:  http://myrepo/mypath/_automation  (defined in Jenkins UI: "Jenkinsfile from SCM field") Single poll:    http://myrepo/mypath/   (defined in Jenkinsfile "checkout/remote" field) 

 

Started on Aug 24, 2018 5:27:00 PM
Received SCM poll call on master for myproject on Aug 24, 2018 5:27:00 PM
Using sole credentials jenkins/** in realm ‘//myrepo:80> svn’
http://myrepo/mypath/_automation is at revision 52,301
Received SCM poll call on master for myproject on Aug 24, 2018 5:27:00 PM
Using sole credentials jenkins/** in realm ‘//myrepo:80> svn’
http://myrepo/mypath/_automation is at revision 52,301
Received SCM poll call on master for myproject on Aug 24, 2018 5:27:00 PM
Using sole credentials jenkins/** in realm ‘//myrepo:80> svn’
http://myrepo/mypath is at revision 52,313
Received SCM poll call on master for myproject on Aug 24, 2018 5:27:00 PM
Using sole credentials jenkins/** in realm ‘//myrepo:80> svn’
http://myrepo/mypath/_automation is at revision 52,301
Received SCM poll call on master for myproject on Aug 24, 2018 5:27:00 PM
Using sole credentials jenkins/** in realm ‘//myrepo:80> svn’
http://myrepo/mypath/_automation is at revision 52,301
Done. Took 98 ms
No changes
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Sure thing, here it is:  

 

pipeline {
agent none
environment {
SVN_CREDENTIALS = credentials('credentialsid')
}
triggers {
pollSCM('H/2 * * * *')
upstream(
upstreamProjects: 'several/upstream/projects',
threshold: hudson.model.Result.SUCCESS
) 
}
stages {
stage('Checkout') {
agent {
label 'docker && windows'
}
steps {
checkout([
$class: 'SubversionSCM', 
locations: [[
credentialsId: '{credentialsid}', 
local: '.', 
remote: '{my_project_url}']], 
workspaceUpdater: [$class: 'UpdateUpdater']])
}
}
stage('Build with Conan') {
parallel {
stage('build_mips'){
agent {
label 'docker && windows'
}
steps {
bat 'python build.py'
}
}
stage('build_arm'){
agent {
label 'docker && windows'
}
steps {
bat 'python build.py'
}
}
stage('build_msvc_15'){
agent {
label 'docker && windows'
}
steps {
bat 'python build.py'
}
}
stage('build_gcc_49'){
agent {
label 'docker && windows'
}
steps {
bat 'python build.py'
}
}
}
}
}
}
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
   

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse commented on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Very relevant update. For one of the jobs, I took the stages out of the `parallel` block, and then scheduled it to run every 24 hours. We have seen had no failures on that job.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse edited a comment on  JENKINS-53140  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
 Very relevant update.  For one of the jobs, I took the stages out of the `parallel` block, and then scheduled it to run every 24 hours.  We have seen had no failures on that job , which is about 20 runs .   Again, previously, it was failing for 1 out of every 10 or so. 
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
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-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-53140  
 
 
  Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 On a new Jenkins server, we're setting up new Jenkinsfiles from scratch.  We're using parallel stages, which seems like it might be a factor based on searches for related issues. We have about 15 of these jobs with 4 parallel stages.  For about 1 in 10 jobs, a stage will randomly fail in 1 second or less.  If you hover over the stage it shows: {code:java}Failed to parse /var/lib/jenkins/jobs/MyOrg/jobs/Projects/jobs/myProject/builds/252/changelog3.xml{code}If you click the Stage Log it says: {code:java}No changes for  since the previous build`{code}This can happen when the build is triggered by either of the following means: * From an upstream job * Manually by clicking "build now" Of note, we use SVN as our SCM with the following configuration:We use "Jenkinsfile from SCM", using URL like {code:java}http://myserver/myrepo/_automation{code}In the GUI, we do not configure SCM polling In the Jenkinsfile, we configure SCM polling, every 2 minutesIn the Jenkinsfile, we configure SCM checkout of  {code:java}http://myserver/myrepo`|http://myserver/myrepo{code} The reason I include our SVN/SCM backstory is because we're also seeing another anomaly related to SCM which might be relevant. . For each SCM polling period, the Subversion Polling Log show approximately multiple entries all at the same timestamp.   These entries are some randomized mix of polling the two relevant URL's :{code:java}http://myserver/myrepo{code} and   {code:java}  http://myserver/myrepo/_automation{code}Interestingly, we've figured something out about these duplicate "Subversion Polling Entries" .  There is 1  entry checking {code:java}http://myserver/myrepo/_automation{code}  for  changes for  each stage in the build  for the " .  So, if we have 1 "Checkout Stage", 1 "Parallel Stages" block, and 3 "Parallel Stages", we see 5 total "Subversion Polling Entries"  for {code:java}http://myserver/myrepo/_automation{code} .  Not sure if this is by design or not. We have the latest versions of all plugins.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 
   

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-53140  
 
 
  Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 On a new Jenkins server, we're setting up new Jenkinsfiles from scratch.  We're using parallel stages, which seems like it might be a factor based on searches for related issues. We have about 15 of these jobs with 4 parallel stages.  For about 1 in 10 jobs, a stage will randomly fail in 1 second or less.  If you hover over the stage it shows: {code:java}Failed to parse /var/lib/jenkins/jobs/MyOrg/jobs/Projects/jobs/myProject/builds/252/changelog3.xml{code}If you click the Stage Log it says: {code:java}No changes for  since the previous build`{code}This can happen when the build is triggered by either of the following means: * From an upstream job * Manually by clicking "build now" Of note, we use SVN as our SCM with the following configuration:We use "Jenkinsfile from SCM", using URL like {code:java}http://myserver/myrepo/_automation{code}In the GUI, we do not configure SCM polling In the Jenkinsfile, we configure SCM polling, every 2 minutesIn the Jenkinsfile, we configure SCM checkout of  {code:java}http://myserver/myrepo`|http://myserver/myrepo{code} The reason I include our SVN/SCM backstory is because we're also seeing another anomaly related to SCM which might be relevant. . For each SCM polling period, the Subversion Polling Log show approximately  4-8  multiple  entries all at the same timestamp.   These entries are some randomized mix of polling the two relevant URL's :{code:java}http://myserver/myrepo{code} and  http://myserver/myrepo/_automation{code} Interestingly, we've figured something out about these duplicate "Subversion Polling Entries" .  There is 1 for each stage in the build.  So, if we have 1 "Checkout Stage", 1 "Parallel Stages" block, and 3 "Parallel Stages", we see 5 total "Subversion Polling Entries".  Not sure if this is by design or not.  We have the latest versions of all plugins.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 
   

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-53140  
 
 
  Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
Change By: 
 jerry wiltse  
 

  
 
 
 
 

 
 On a new Jenkins server, we're setting up new Jenkinsfiles from scratch.  We're using parallel stages, which seems like it might be a factor based on searches for related issues. We have about 15 of these jobs with 4 parallel stages.  For about 1 in 10 jobs, a stage will randomly fail in 1 second or less.  If you hover over the stage it shows:  {code:java}  ` Failed to parse /var/lib/jenkins/jobs/MyOrg/jobs/Projects/jobs/myProject/builds/252/changelog3.xml ` {code}   If you click the Stage Log it says:  ` {code:java} No changes for  since the previous build` {code} This can happen when the build is triggered by either of the following means: * From an upstream job * Manually by clicking "build now" Of note, we use SVN as our SCM with the following configuration:We use "Jenkinsfile from SCM", using URL like  `  {code:java} http://myserver/myrepo/_automation ` {code} In the GUI, we do not configure SCM polling In the Jenkinsfile, we configure SCM polling, every 2 minutesIn the Jenkinsfile, we configure SCM checkout of   `[  {code:java} http://myserver/myrepo`|http://myserver/myrepo ] {code}  The reason I include our SVN/SCM backstory is because we're also seeing another anomaly related to SCM which might be relevant. . For each SCM polling period, the Subversion Polling Log show approximately 4-8 entries all at the same timestamp.   These entries are some randomized mix of polling the two relevant URL's : ` {code:java} http://myserver/myrepo ` {code}  and   ` http://myserver/myrepo/_automation ` {code}  We have the latest versions of all plugins.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 
   

[JIRA] (JENKINS-53140) Intermittent Random Stage Failures - No Changes Detected - Parallel Stages

[jerrywil...@gmail.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 jerry wiltse created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-53140  
 
 
  Intermittent Random Stage Failures - No Changes Detected - Parallel Stages   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2018-08-20 15:26  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 jerry wiltse  
 

  
 
 
 
 

 
 On a new Jenkins server, we're setting up new Jenkinsfiles from scratch.  We're using parallel stages, which seems like it might be a factor based on searches for related issues.  We have about 15 of these jobs with 4 parallel stages.  For about 1 in 10 jobs, a stage will randomly fail in 1 second or less.  If you hover over the stage it shows:  `Failed to parse /var/lib/jenkins/jobs/MyOrg/jobs/Projects/jobs/myProject/builds/252/changelog3.xml` If you click the Stage Log it says:  `No changes for  since the previous build` This can happen when the build is triggered by either of the following means: 
 
From an upstream job 
Manually by clicking "build now" 
   Of note, we use SVN as our SCM with the following configuration: We use "Jenkinsfile from SCM", using URL like `http://myserver/myrepo/_automation` In the GUI, we do not configure SCM polling  In the Jenkinsfile, we configure SCM polling, every 2 minutes In the Jenkinsfile, we configure SCM checkout of  `http://myserver/myrepo`   The reason I include our SVN/SCM backstory is because we're also seeing another anomaly related to SCM which might be relevant. .  For each SCM polling period, the Subversion Polling Log show approximately 4-8 entries all at the same timestamp.   These entries are some randomized mix of polling the two relevant URL's : `http://myserver/myrepo` and  `http://myserver/myrepo/_automation`           We have the latest versions of all plugins.