Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/org/jenkinsci/plugins/workflow/cps/CpsThreadTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/df875e708dfd2e0cfeb1f8aa030c9eb706705a5f
Log:
JENKINS-46076 Noting location of flake.

I believe this one was resolved in my 1Q/2Q 2018 work to resolve persistence and order of operation issues. We can re-open if it recurs though.

Just saw this again today locally building 561de1059c.

I saw this flake again today along with ParallelStepTest.failureReporting. Both failed looking for Finished: $RESULT. I think it might have to do with a similar problem I ran into in Declarative which I worked around by adding a sleep when checking the build result fails and checking again, see here.

I think this is a race condition between waitForMessage and WorkflowRun.finish. The latter sets a completed flag prior to calling BuildListener.finished. The former stops waiting for a message once the build is marked complete. Either finish should be reordered a bit, or waitForMessage should wait for Finished: to appear after !logUpdated. Alternately, individual tests can just avoid using waitForMessage on Finished: … arguments and implement it directly, as I have done in a couple places.

Reproducible with

diff --git a/pom.xml b/pom.xml
index 3e1b3830..41948296 100644
--- a/pom.xml
+++ b/pom.xml
@@ -84,7 +84,7 @@
         <dependency>
             <groupId>org.jenkins-ci.plugins.workflow</groupId>
             <artifactId>workflow-api</artifactId>
-            <version>2.30</version>
+            <version>2.32</version>
         </dependency>
         <dependency>
             <groupId>org.jenkins-ci.plugins.workflow</groupId>
@@ -152,7 +152,7 @@
         <dependency>
             <groupId>org.jenkins-ci.plugins.workflow</groupId>
             <artifactId>workflow-job</artifactId>
-            <version>2.26</version>
+            <version>2.33-SNAPSHOT</version>
             <scope>test</scope>
         </dependency>
         <dependency>

picking up

diff --git a/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java b/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
index 2eaac3a..f630809 100644
--- a/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
+++ b/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
@@ -577,6 +577,11 @@ public final class WorkflowRun extends Run<WorkflowJob,WorkflowRun> implements F
             completed = Boolean.TRUE;
             duration = Math.max(0, System.currentTimeMillis() - getStartTimeInMillis());
         }
+        try {
+            Thread.sleep(3_000);
+        } catch (InterruptedException x) {
+            x.printStackTrace();
+        }
         try {
             LOGGER.log(Level.INFO, "{0} completed: {1}", new Object[]{toString(), getResult()});
             if (nullListener) {

Still one PR open, but originally reported test flake should now be addressed.

Hi jglick, I believe this ticked caused an issue with our jenkins instance.

The issue I was seeing was causing builds to be stuck forever in queue -

I ran 

Jenkins.instance.getItemByFullName(...).getBuildByNumber(..).isLogUpdated()

On the previous build, and the result was true. I believe this was causing the blockage.

A downgrade to workflow-job 2.32 fixed the issue for us. I can gather more information if you like and try to reproduce the issue on our test instance.

We are using jenkins 2.176.2.

I have attached a list of our plugins as well - plugins.txt

hellspam please file a separate issue, Link’d to this one, with the regression label, and whatever steps to reproduce you can manage to put together.

jglick done - JENKINS-59083

I have also reproduced this issue on our test instance, if you need any more information please let me know.