[JENKINS-52165] Disable watch mode by default for now #84
Conversation
dwnusbaum
left a comment
dwnusbaum
left a comment
There was a problem hiding this comment.
Ok, given the various issues I think it makes sense to go ahead and disable it until we have time to investigate.
| @SuppressFBWarnings(value = "MS_SHOULD_BE_FINAL", justification = "public & mutable only for tests") | ||
| @Restricted(NoExternalUse.class) | ||
| public static boolean USE_WATCHING = !"false".equals(System.getProperty(DurableTaskStep.class.getName() + ".USE_WATCHING")); | ||
| public static boolean USE_WATCHING = Boolean.parseBoolean(System.getProperty(DurableTaskStep.class.getName() + ".USE_WATCHING", Main.isUnitTest ? "true" : /* JENKINS-52165 turn back on by default */ "false")); |
There was a problem hiding this comment.
It seems undesirable to not actually test using the mode that we are shipping to users, but I also see why it would be good to test against watch mode since any issues in downstream plugins are likely to be specific to that mode, so I am somewhat split on this.
There was a problem hiding this comment.
It seems undesirable to not actually test using the mode that we are shipping to users
Indeed. On the other hand the non-watch mode has been tested for years, and I certainly hope this situation will be temporary.
There was a problem hiding this comment.
I'm okay with this part -- not perfect but it'll do. Just trying to check that the exit condition stuff is 100% the same internally.
|
I was curious to see what tests failed if I did not use watch mode for tests, and among the expected failures related to remote logging, the tests for my recent JENKINS-28822 fix started failing, because I only fixed it for watch mode. It would be ideal to modify that fix to work for non-watch mode as well, or we'd need to reopen the issue. To fix it, we'd need to reproduce the logic related to |
#75 FTR. Indeed, that fix needs to be extended to work in both modes. I will check it. |
| // Would have succeeded before https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/75. | ||
| j.assertBuildStatus(Result.ABORTED, b); | ||
| j.assertLogContains("Timeout has been exceeded", b); | ||
| j.waitForMessage("Timeout has been exceeded", b); // TODO assertLogContains fails unless a sleep is introduced; possible race condition in waitForCompletion |
There was a problem hiding this comment.
I saw this as well, although it passed sometimes in my local testing, so some kind of race condition seems likely.
| Throwable originalCause = causeOfStoppage; | ||
| if ((returnStatus && originalCause == null) || exitCode == 0) { | ||
| getContext().onSuccess(returnStatus ? exitCode : returnStdout ? new String(output, StandardCharsets.UTF_8) : null); | ||
| getContext().onSuccess(returnStatus ? exitCode : returnStdout ? new String(output.produce(), StandardCharsets.UTF_8) : null); |
There was a problem hiding this comment.
🐜 Nested ternary operators are super hard to read for most developers without line breaks between them
There was a problem hiding this comment.
Perhaps. Anyway that predates this PR.
svanoort
left a comment
svanoort
left a comment
There was a problem hiding this comment.
Looks okay to me, let's release. BUT, I think we need a clean reproduction and verify-that-it's-fixed before we can release workflow-job again.
svanoort
left a comment
svanoort
left a comment
There was a problem hiding this comment.
Looks okay to me, let's release. BUT, I think we need a clean reproduction and verify-that-it's-fixed before we can release workflow-job again.
|
Double approval could be because I approve extra hard... or because conference wifi sucks. You decide! |
[JENKINS-52165] Disable watch mode by default for now
3 participants
Disabling #63 to buy some time until I can fix some acknowledged issues (mainly JENKINS-54133 and waiting for the maintainer on JENKINS-54081) and properly investigate some reported issues which are likely linked (JENKINS-54073 and JENKINS-53888). Complements jenkins-infra/update-center2#247. jenkinsci/workflow-basic-steps-plugin#74 is still needed promptly since that seems to be independent.
Note that this retains watch mode in tests, to continue to enforce coverage in this plugin and in any other pkugins which currently have a test dep on 2.22+ which might bump up their dep to 2.25.