[JENKINS-49073] Parallel step should propagate the worst result when not using failFast #325

basil · 2019-09-18T19:31:36Z

Problem

Solution

Inspired by jenkinsci/pipeline-build-step-plugin#24 (comment). Add a new propagateWorst property to the parallel step that implements the desired behavior. When this is in effect, the "worst" branch propagates its build status, as defined by the ordering Jesse suggested.

Implementation

To make this change easier to implement, I first did two commits that simply refactor the existing code. These should be reviewed first to ensure that I didn't break anything.

The first commit simplifies originalFailure from a SimpleEntry<String,Throwable> to just a Throwable. The key was never used, so this is just a simplification.
The second commit changes the saved on-disk state from the first failure with all subsequent failures chained onto it via suppressed exceptions to a LinkedHashSet of failures in insertion order. This allows us to delay choosing the top-level exception until later in the execution in checkAllDone, which is needed in order to implement the new propagateWorst functionality.

basil · 2019-09-18T19:32:12Z

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

+
+    @Issue("JENKINS-49073")
+    @Test
+    public void parallelPropagatesStatus() throws Exception {


I added these new test cases, which exercise the new functionality and fail prior to this change. Are there any other use cases I should consider or test cases I should write?

jglick

Looks nice from a quick glance; have not yet done a detailed review of the logic.

src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

jglick · 2019-09-18T19:44:51Z

pom.xml

@@ -167,6 +167,12 @@
            <version>1.11</version>
            <scope>test</scope>
        </dependency>
+        <dependency>
+            <groupId>org.jenkins-ci.plugins</groupId>
+            <artifactId>pipeline-build-step</artifactId>


Unnecessary I think; pending JENKINS-27092, can use non-sandboxed scripts which directly throw new FlowInterruptedException(…) for tests.

Perhaps this isn't necessary, but I think it makes the test more realistic. I saw that we're already pulling in pipeline-input-step, so pulling in pipeline-build-step as well didn't seem like a big price to pay for the benefit of more realistic integration testing. I think I'd rather keep this as-is, but let me know if you feel strongly otherwise.

No strong feeling.

Personally, I'd lean towards the FlowInterruptedException approach since it would make parallelPropagatesStatusImpl much easier to read, but I think either approach is fine.

…sts on Windows

basil · 2019-09-27T19:27:12Z

My most recent test run failed due to an issue that doesn't look related to this change:

[ERROR] inProgressButProgramLoadFailure(org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest)  Time elapsed: 195.219 s  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 180 seconds
	at java.lang.Thread.sleep(Native Method)
	at org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest.assertCompletedCleanly(PersistenceProblemsTest.java:56)
	at org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest.lambda$inProgressButProgramLoadFailure$19(PersistenceProblemsTest.java:321)
	at org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest$$Lambda$2/1166807841.run(Unknown Source)
	at org.jvnet.hudson.test.RestartableJenkinsRule$3.evaluate(RestartableJenkinsRule.java:200)
	at org.jvnet.hudson.test.RestartableJenkinsRule$6.evaluate(RestartableJenkinsRule.java:240)
	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:556)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:748)

Restarting to get another build.

basil · 2019-09-27T19:34:49Z

Now all branches of my build failed without even running a single test. I'm just going to give up for today and try to run a build again tomorrow.

slonopotamus · 2019-09-30T10:26:09Z

How propagateWorst=true interacts with failFast=true?
I'd like propagateWorst=true to be default. What is the procedure of discussing this design decision?

basil · 2019-09-30T15:55:24Z

Now all branches of my build failed without even running a single test. I'm just going to give up for today and try to run a build again tomorrow.

I got further today. My test run passed in all environments except in windows-11-2.164.1, where the following two errors occurred:

[ERROR] Tests run: 11, Failures: 0, Errors: 1, Skipped: 2, Time elapsed: 218.424 s <<< FAILURE! - in org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest
[ERROR] inProgressButProgramLoadFailure(org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest)  Time elapsed: 192.424 s  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 180 seconds
	at java.base@11.0.3/java.lang.Thread.sleep(Native Method)
	at app//org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest.assertCompletedCleanly(PersistenceProblemsTest.java:56)
	at app//org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest.lambda$inProgressButProgramLoadFailure$19(PersistenceProblemsTest.java:321)
	at app//org.jenkinsci.plugins.workflow.cps.PersistenceProblemsTest$$Lambda$67/0x0000000100125c40.run(Unknown Source)
	at app//org.jvnet.hudson.test.RestartableJenkinsRule$3.evaluate(RestartableJenkinsRule.java:200)
	at app//org.jvnet.hudson.test.RestartableJenkinsRule$6.evaluate(RestartableJenkinsRule.java:240)
	at app//org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:556)
	at app//org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at app//org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.base@11.0.3/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base@11.0.3/java.lang.Thread.run(Thread.java:834)

[ERROR] Tests run: 15, Failures: 1, Errors: 0, Skipped: 4, Time elapsed: 188.762 s <<< FAILURE! - in org.jenkinsci.plugins.workflow.cps.FlowDurabilityTest
[ERROR] testCompleteAndLoadBuilds(org.jenkinsci.plugins.workflow.cps.FlowDurabilityTest)  Time elapsed: 4.283 s  <<< FAILURE!
org.junit.ComparisonFailure: 
expected:<...e] End of Pipeline
[]> but was:<...e] End of Pipeline
[Finished: SUCCESS
]>
	at org.junit.Assert.assertEquals(Assert.java:115)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.jenkinsci.plugins.workflow.cps.FlowDurabilityTest$2.evaluate(FlowDurabilityTest.java:420)
	at org.jvnet.hudson.test.RestartableJenkinsRule$6.evaluate(RestartableJenkinsRule.java:240)
	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:556)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:834)

I can't reproduce these locally and they don't appear to be related to my changes. I'll leave it to the maintainers to comment on any possible next steps here.

basil · 2019-09-30T16:00:09Z

How propagateWorst=true interacts with failFast=true?

The two are mutually exclusive and an IllegalArgumentException is thrown if one attempts to use both simultaneously (see f1c1968).

I'd like propagateWorst=true to be default. What is the procedure of discussing this design decision?

I would also like it to be the default, but I erred on the conservative side in this change. There is precedent for changing existing behavior (and breaking backward compatibility!) to adopt a more sensible default in jenkinsci/pipeline-build-step-plugin#24 (comment):

though I think the behavior in this PR is a natural default

Given this past precedent, it seems possible to change the default behavior of the parallel step to propagate the worst result by default, and (to me) this seems like a "natural default", but I defer to the judgment of the maintainers regarding this matter.

dwnusbaum · 2019-10-02T13:49:19Z

@basil Before jenkinsci/pipeline-build-step-plugin#24, was there any normal scenario in which users would care about the difference between propagate: true vs propagate: false ? The only one I can think of is for users manually throwing FlowInterruptedException, but I don't know how common that is. I am thinking it would be better to just make propagate: true the default so we don't have another option, but that depends on whether users care about the previous behavior.

basil · 2019-10-02T15:27:52Z

Before jenkinsci/pipeline-build-step-plugin#24, was there any normal scenario in which users would care about the difference between propagate: true vs propagate: false?

I think you meant to ask if there was any normal scenario in which users would care about the difference between propagateWorst: true vs propagateWorst: false in the parallel step (i.e., what I am proposing in this PR) rather than propagate: true and propagate: false in the build step (which is what was affected in jenkinsci/pipeline-build-step-plugin#24). So I'll answer the question I think you meant to ask. But if you really did mean to ask about the behavior of the build step, let me know and we can discuss that as well.

I took a look at the 116 Pipeline jobs in use at my company, and I didn't find a single instance where the author manually threw a FlowInterruptedException. In all the cases where we are using parallel steps (without failFast: true), we had initially expected the worst result to be propagated and were surprised when it wasn't. To work around this, we wrote the code described in JENKINS-49073 (comment). This is why I think propagating the worst result would be a natural default (when failFast: true is not being used).

Based on the above, I think we have a few options:

The most conservative option is to preserve the existing behavior (propagate the first result) by default, add a new option to propagate the worst result (off by default), and fail with an IllegalStateException when propagateWorst is used with failFast.
The simplest option is to propagate the worst result by default (a change in existing behavior), except when failFast is set. No new syntax would be added to the API. When failFast is set, we'd continue to propagate the first result as we do today, but there would no longer be a way to propagate the first result if failFast is not set.
A compromise would be to propagate the worst result by default (a change in existing behavior), except when failFast is set, but to also add a new propagateFirst option, which could be used if you want to get the old behavior of propagating the first result without setting failFast.

I personally don't think there is a real use case for propagating the first result without setting failFast. At least I have never wanted this in any of my pipelines. So I dislike option 3 because it unnecessarily complicates the API. So for me the real choice is between option 1 and option 2. Since I think propagating the worst result by default (except when failFast is set) is the most natural default, I personally favor option 2 (knowing that it breaks backward compatibility). Another reason to favor option 2 is that it keeps the syntax simple and avoids having to throw an IllegalArgumentException when failFast is used with propagateWorst.

…ugin into propagate

dwnusbaum · 2019-10-30T19:29:42Z

@basil I think option 2 seems like the most obvious behavior. Unfortunately, we have no real way to know how many users might be relying on the existing behavior, but given that users would have to be manually throwing FlowInterruptedException to notice a difference, it seems safe enough to change the default behavior, so my vote is for option 2.

…is not set

basil · 2019-10-31T20:17:22Z

Sounds good to me! I've updated the change to propagate the worst result by default when failFast is false and removed the propagateWorst setting.

basil · 2019-10-31T21:41:11Z

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.UNSTABLE, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.UNSTABLE, Result.FAILURE, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.NOT_BUILT, Result.NOT_BUILT);


I'm not entirely satisfied with how the code is currently working for these test cases. For example, for three parallel builds whose results are SUCCESS, UNSTABLE, and NOT_BUILT we are currently propagating a status of NOT_BUILT. I don't consider this ideal; to me, UNSTABLE is "worse" than NOT_BUILT. Similarly, for four parallel builds whose results are SUCCESS, UNSTABLE, FAILURE, and NOT_BUILT we are currently propagating a status of NOT_BUILT. I don't consider this ideal; to me, FAILURE is "worse" than NOT_BUILT. Finally, for two parallel builds whose status is SUCCESS and NOT_BUILT we are currently propagating a status of NOT_BUILT. This doesn't make sense to me. If all the child jobs had a status of NOT_BUILT, then I could understanding the parent job having a status of NOT_BUILT, but as long as a single child job has a status of SUCCESS, I would expect that to be propagated to the parent.

I will think some more about how to tweak the comparator algorithm to handle these cases.

Another tricky question is how to handle ABORTED. Between SUCCESS and ABORTED, ABORTED is clearly worse. But what about between FAILURE/UNSTABLE and ABORTED? I would argue that FAILURE/UNSTABLE are "worse", because we know the status of the failed/unstable job (whereas we don't know the status of the aborted job, which never ran to completion). Between NOT_BUILT and ABORTED I think ABORTED is worse.

Re: What result is worst, I would just use the ordering defined by Result.ordinal (used to implement Result.isWorseThan and friends). Whether that ordering makes the most sense could be debated, but that's the ordering that everything else in Jenkins uses, so I would use it here as well.

Might be interesting to run pipeline-model-definition's tests with this change to see if any of them start failing.

Re: What result is worst, I would just use the ordering defined by Result.ordinal (used to implement Result.isWorseThan and friends). Whether that ordering makes the most sense could be debated, but that's the ordering that everything else in Jenkins uses, so I would use it here as well.

My comparison logic is already using Result#isWorseThan and Result#isBetterThan, so if we're OK with the behavior demonstrated by the new tests (which I think is acceptable, but not ideal) then I can leave the comparison logic as-is.

Might be interesting to run pipeline-model-definition's tests with this change to see if any of them start failing.

Sure. I opened jenkinsci/pipeline-model-definition-plugin#360 to cover this testing.

I opened jenkinsci/pipeline-model-definition-plugin#360 to cover this testing.

These tests passed.

To elaborate on my earlier comment, the values in Result have always seemed weird to me. ABORTED and NOT_BUILT feel like a different kind of thing entirely than SUCCESS, FAILURE, and UNSTABLE. Sometimes I think it would have made more sense for results to have 2 parts, a "completion" result, like , NOT_BUILT, ABORTED, COMPLETED, and a "goodness" result, like SUCCESS, WARNING, ERROR. Then you could have something like a Pipeline step that is ABORTED and SUCCESS in the case of a user cancelling the build, or ABORTED and WARNING in the case of something like a timeout, NOT_BUILT and SUCCESS could be used in cases like a Declarative when expression that is false, and here in the parallel step, the completion result would always be COMPLETED, and only the "goodness" result would be determined by the results of the branches. Using two values creates other problems though, and not all combinations make sense.

So all that to say, I agree that the behavior here with NOT_BUILT feels wrong, but I'm not sure if it makes sense to try to change it.

I agree with your observations here. The awkwardness in the use cases I described above is exposing a deeper problem in how the Result API is defined in Jenkins core. When I get a chance I'll try to file a bug/RFE against Jenkins core with the results of this discussion. Perhaps one day that can be addressed, but I agree that it is quite orthogonal to this effort.

…plugin#325.

dwnusbaum

Looks ok to me in general, added some minor comments.

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java

dwnusbaum · 2019-11-01T19:37:53Z

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.UNSTABLE, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.SUCCESS, Result.UNSTABLE, Result.FAILURE, Result.NOT_BUILT);
+                parallelPropagatesStatusImpl(
+                        Result.NOT_BUILT, Result.NOT_BUILT, Result.NOT_BUILT);


To elaborate on my earlier comment, the values in Result have always seemed weird to me. ABORTED and NOT_BUILT feel like a different kind of thing entirely than SUCCESS, FAILURE, and UNSTABLE. Sometimes I think it would have made more sense for results to have 2 parts, a "completion" result, like , NOT_BUILT, ABORTED, COMPLETED, and a "goodness" result, like SUCCESS, WARNING, ERROR. Then you could have something like a Pipeline step that is ABORTED and SUCCESS in the case of a user cancelling the build, or ABORTED and WARNING in the case of something like a timeout, NOT_BUILT and SUCCESS could be used in cases like a Declarative when expression that is false, and here in the parallel step, the completion result would always be COMPLETED, and only the "goodness" result would be determined by the results of the branches. Using two values creates other problems though, and not all combinations make sense.

So all that to say, I agree that the behavior here with NOT_BUILT feels wrong, but I'm not sure if it makes sense to try to change it.

dwnusbaum · 2019-11-01T19:42:01Z

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStepTest.java

+
+    private FreeStyleProject getDownstreamJob(Result result) throws IOException {
+        FreeStyleProject ds = story.j.createFreeStyleProject();
+        ds.getBuildersList().add(new TestBuilder() {


nit: Maybe simpler to use a Pipeline job for the downstream builds instead:

WorkflowJob ds = story.j.createProject(WorkflowJob.class); ds.setDefinition(new CpsFlowDefinition("currentBuild.result = " + result, true));

I don't think it makes a big difference one way or the other. I did it this way simply because I was copying an existing example from the pipeline-build-step plugin's tests.

dwnusbaum · 2019-11-01T19:47:27Z

pom.xml

@@ -167,6 +167,12 @@
            <version>1.11</version>
            <scope>test</scope>
        </dependency>
+        <dependency>
+            <groupId>org.jenkins-ci.plugins</groupId>
+            <artifactId>pipeline-build-step</artifactId>


Personally, I'd lean towards the FlowInterruptedException approach since it would make parallelPropagatesStatusImpl much easier to read, but I think either approach is fine.

Co-Authored-By: Devin Nusbaum <dwnusbaum@users.noreply.github.com>

dwnusbaum · 2019-11-25T19:31:24Z

@basil My suggestions were a bit messed up and incomplete, so I filed basil#1 for improvements. It would be great if you could take a look at that PR and merge it in if you are ok with the changes.

Improve review suggestions

basil · 2019-11-25T20:19:39Z

@basil My suggestions were a bit messed up and incomplete, so I filed basil#1 for improvements. It would be great if you could take a look at that PR and merge it in if you are ok with the changes.

Thanks for helping me take this across the finish line! At this point I think the only remaining change we need to make is to release pipeline-build-step and resolve the TODO in pom.xml in this PR by pulling in the released version.

pom.xml

Co-Authored-By: Devin Nusbaum <dwnusbaum@users.noreply.github.com>

basil added 4 commits September 18, 2019 11:30

Simplify originalFailure to make future implementation easier

1d6a69b

Refactor suppression attachment to make future implementation easier

78fa54b

Pull in pipline-build-step

1b8ab5e

Parallel step should offer the ability to propagate the worst result

d5c1e58

basil commented Sep 18, 2019

View reviewed changes

basil mentioned this pull request Sep 18, 2019

[JENKINS-49073] Propagate the downstream result, not just FAILURE jenkinsci/pipeline-build-step-plugin#24

Merged

jglick requested review from jglick and dwnusbaum September 18, 2019 19:38

jglick reviewed Sep 18, 2019

View reviewed changes

jglick self-requested a review September 18, 2019 19:45

basil added 2 commits September 18, 2019 13:58

Review feedback, SpotBugs

f1c1968

Fix flaky test

a9044ef

basil closed this Sep 27, 2019

basil reopened this Sep 27, 2019

Use waitForMessage() rather than assertLogContains() to try to fix te…

5561759

…sts on Windows

basil closed this Sep 27, 2019

basil reopened this Sep 27, 2019

basil closed this Sep 30, 2019

basil reopened this Sep 30, 2019

basil mentioned this pull request Sep 30, 2019

No-op change #326

Closed

Merge branch 'master' of https://github.com/jenkinsci/workflow-cps-pl…

6703ac9

…ugin into propagate

Merge remote-tracking branch 'origin/master' into propagate

23dee2c

basil added 3 commits October 31, 2019 13:08

Make propagating the worst result the default behavior when failFast …

064a590

…is not set

Centralize documentation in Javadoc

d8e5b7c

Forgot to remove the usage of propagateWorst in test code.

ebb8674

basil changed the title ~~Parallel step should offer the ability to propagate the worst result~~ [JENKINS-49073] Parallel step should offer the ability to propagate the worst result Oct 31, 2019

basil added 2 commits October 31, 2019 14:25

Avoid unnecessary list copying in comparator

00b4033

Add additional test cases

1f2e0f4

basil commented Oct 31, 2019

View reviewed changes

Merge remote-tracking branch 'origin/master' into propagate

7b292ae

basil added a commit to basil/pipeline-model-definition-plugin that referenced this pull request Nov 1, 2019

Run pipeline-model-definition's tests against jenkinsci/workflow-cps-…

74a5df3

…plugin#325.

basil mentioned this pull request Nov 1, 2019

[Do not merge] Demonstrate compatibility with jenkinsci/workflow-cps-plugin#325 jenkinsci/pipeline-model-definition-plugin#360

Closed

dwnusbaum approved these changes Nov 1, 2019

View reviewed changes

basil and others added 2 commits November 4, 2019 09:49

Apply suggestions from code review

17747e6

Co-Authored-By: Devin Nusbaum <dwnusbaum@users.noreply.github.com>

Improve review suggestions

72b275d

basil added 2 commits November 25, 2019 11:54

Merge pull request #1 from dwnusbaum/parallel-results

8a01e6e

Improve review suggestions

Rewrap lines

b8b3840

dwnusbaum approved these changes Nov 25, 2019

View reviewed changes

dwnusbaum requested a review from bitwiseman November 25, 2019 19:59

bitwiseman approved these changes Nov 26, 2019

View reviewed changes

dwnusbaum reviewed Nov 26, 2019

View reviewed changes

pom.xml Outdated Show resolved Hide resolved

Update pom.xml

dfb4d12

Co-Authored-By: Devin Nusbaum <dwnusbaum@users.noreply.github.com>

dwnusbaum changed the title ~~[JENKINS-49073] Parallel step should offer the ability to propagate the worst result~~ [JENKINS-49073] Parallel step should propagate the worst result when not using failFast Nov 26, 2019

dwnusbaum merged commit f005885 into jenkinsci:master Nov 26, 2019

basil deleted the propagate branch November 23, 2021 17:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[JENKINS-49073] Parallel step should propagate the worst result when not using failFast #325

[JENKINS-49073] Parallel step should propagate the worst result when not using failFast #325

basil commented Sep 18, 2019

basil Sep 18, 2019

jglick left a comment

jglick Sep 18, 2019

basil Sep 18, 2019

jglick Sep 18, 2019

dwnusbaum Nov 1, 2019

basil commented Sep 27, 2019

basil commented Sep 27, 2019

slonopotamus commented Sep 30, 2019 •

edited

Loading

basil commented Sep 30, 2019

basil commented Sep 30, 2019

dwnusbaum commented Oct 2, 2019

basil commented Oct 2, 2019

dwnusbaum commented Oct 30, 2019

basil commented Oct 31, 2019

basil Oct 31, 2019 •

edited

Loading

basil Oct 31, 2019

dwnusbaum Nov 1, 2019

basil Nov 1, 2019

basil Nov 1, 2019

dwnusbaum Nov 1, 2019

basil Nov 25, 2019

dwnusbaum left a comment

dwnusbaum Nov 1, 2019

dwnusbaum Nov 1, 2019

basil Nov 25, 2019

dwnusbaum Nov 1, 2019

dwnusbaum commented Nov 25, 2019 •

edited

Loading

basil commented Nov 25, 2019

[JENKINS-49073] Parallel step should propagate the worst result when not using failFast #325

[JENKINS-49073] Parallel step should propagate the worst result when not using failFast #325

Conversation

basil commented Sep 18, 2019

Problem

Solution

Implementation

Choose a reason for hiding this comment

jglick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

basil commented Sep 27, 2019

basil commented Sep 27, 2019

slonopotamus commented Sep 30, 2019 • edited Loading

basil commented Sep 30, 2019

basil commented Sep 30, 2019

dwnusbaum commented Oct 2, 2019

basil commented Oct 2, 2019

dwnusbaum commented Oct 30, 2019

basil commented Oct 31, 2019

basil Oct 31, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dwnusbaum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dwnusbaum commented Nov 25, 2019 • edited Loading

basil commented Nov 25, 2019

slonopotamus commented Sep 30, 2019 •

edited

Loading

basil Oct 31, 2019 •

edited

Loading

dwnusbaum commented Nov 25, 2019 •

edited

Loading