Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46076

Test flake in CpsThreadTest.stop

XMLWordPrintable

    • workflow-job 2.33 

      java.lang.AssertionError: 
Expected: a string containing "Finished: ABORTED"
     but: was "Started
[Pipeline] unkillable
Aborted by unknown
[Pipeline] End of Pipeline
"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at org.junit.Assert.assertThat(Assert.java:923)
	at org.jvnet.hudson.test.JenkinsRule.assertLogContains(JenkinsRule.java:1215)
	at org.jvnet.hudson.test.JenkinsRule.waitForMessage(JenkinsRule.java:1263)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadTest.stop(CpsThreadTest.java:70)

      As noted in sources, WorkflowRun.isBuilding() can go to false before .finish has completed.

        1. plugins.txt
          5 kB

          [JENKINS-46076] Test flake in CpsThreadTest.stop

          Jesse Glick created issue -

          SCM/JIRA link daemon added a comment -

          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.

          SCM/JIRA link daemon added a comment - 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.

          Sam Van Oort added a comment -

          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.

          Sam Van Oort added a comment - 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.
          Sam Van Oort made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]

          Devin Nusbaum added a comment -

          Just saw this again today locally building 561de1059c.

          Devin Nusbaum added a comment - Just saw this again today locally building 561de1059c .
          Devin Nusbaum made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Closed [ 6 ] New: Reopened [ 4 ]

          Devin Nusbaum added a comment - - edited

          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.

          Devin Nusbaum added a comment - - edited 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 .

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.
          Jesse Glick made changes -
          Component/s New: jenkins-test-harness [ 21462 ]
          Component/s New: workflow-job-plugin [ 21716 ]
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: