Major There are too many @RandomlyFails tests. SemaphoreStep should be used more consistently in place of WatchYourStep and waiting for the execution to suspend. (Already prototyped in WorkflowTest.env.)
Also any build logs should be streamed immediately to stderr, rather than forcing the test to include the current log in every assertion message observed to fail. (In combination with SemaphoreStep, this should also more reliably flush recent output: WorkflowRun flushes logs when new steps are run.)
- is related to
-
JENKINS-26398 Fix createSlave for RestartableJenkinsRule
-
- Resolved
-
-
JENKINS-26399 Utility method in JenkinsRule to wait for build to complete
-
- Resolved
-
- links to
[JENKINS-25975] More reliable test infrastructure
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Implementing some of these things in PR 59 just to get things to pass on Windows, which is easier using SemaphoreStep than WatchYourStep because we do not need to deal with local file paths embedded in the script.
One class of random failure I think I have diagnosed: CpsThreadGroup.notifyNewHead notifies listeners asynchronously, so WorkflowRun.copyLogs does not run instantly after a step completes, and so the build log may not immediately show its output. CpsFlowExecution.waitForSuspension seems to solve that.
| Remote Link | New: This issue links to "PR 59 (Web Link)" [ 12125 ] |
| Remote Link | New: This issue links to "PR 92 (Web Link)" [ 12166 ] |
| Link |
New:
This issue is related to |
| Link |
New:
This issue is related to |
Code changed in jenkins
User: Jesse Glick
Path:
test/src/main/java/org/jvnet/hudson/test/BuildWatcher.java
test/src/main/java/org/jvnet/hudson/test/JenkinsRule.java
http://jenkins-ci.org/commit/jenkins/9ac2257d0a3fa86928267a82d69d55c5a4e423c1
Log:
[FIXED JENKINS-26399] JENKINS-25975 Merged #1609.
Compare: https://github.com/jenkinsci/jenkins/compare/b02e71e3dfcb...9ac2257d0a3f
I am occasionally getting test failures whereby a sh step is evidently run but its output is not included in the log. I suspect a race condition between the GraphListener calling copyLogs and the one calling PrintStream.close when DefaultStepContext makes a LogActionImpl.
Note to self: if deleting WatchYourStep, can also close PR 10.