gistfile1.txt

[20:11:47] *** josb has joined #jenkins
[20:13:18] <josb> Hi. In the lastest Workflow plugin, 'currentBuild.result = "SUCCESS"' after a failed job doesn't seem to do anything, despite JENKINS-26834. Fyi.
[20:13:20] <jenkins-admin> JENKINS-26834:Direct access to contextual [Workflow]Run (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-26834
[20:14:05] <kohsuke> josb: I think it's Jenkins' core thing. If somebody sets the build as a failure you can't set it back to success
[20:14:09] <kohsuke> josb: what's your use case?
[20:16:30] <josb> kohsuke: I tried to avoid a wrapper build to trigger a build failure of the current build. But then I discovered 'propagate: false' which works for my purpose (thanks for that!)
[20:17:18] <josb> So now I call 'build job: 'foo', propagate: false" inside my main workflow and all is well.
[20:18:11] <josb> My earlier attempt was to set 'currentBuild.result = "SUCCESS" after wrapping the build in a catchError block, but that doesn't work, hence my comment.
[20:18:39] <kohsuke> what does the propagate flag do?
[20:19:25] <josb> kohsuke: it avoids the build in question propagating its failure status to the containing build.
[20:20:04] <josb> kohsuke: I think Jesse Glick added this.
[20:20:15] <kohsuke> Yes, I'm sure
[20:20:56] <kohsuke> OK, I think I got the point. If an exception is thrown after the failure is set, then it's kinda pointless because you cannot recover from it
[20:21:21] <josb> kohsuke: anyway, I thought someone should know. Thanks for listening! I'm really liking where the workflow plugin is going, good job.
[20:21:22] <kohsuke> This should manifest if we do something like "retry(100) { build(job:'foo') }
[20:22:16] <josb> kohsuke: you're probably right; but I didn't try that.
[20:26:01] <kohsuke> josb: oh scratch that, it's the designed behaviour of catchError block
[20:26:09] <kohsuke> It says "it marks the build as failure but continues"
[20:26:14] <kohsuke> not "it ignores the failure and continues"
[20:26:28] <kohsuke> for that you should be using standard try/catch
[20:27:02] <kohsuke> I've been wondering myself why this was any different from try/catch, but now I know
[20:27:55] <kohsuke> I'll add some help text
[20:34:19] <josb> kohsuke: I understand the difference between those two, I think. The issue I am raising is that you are supposed to be able to override the currentBuild.result regardless, but that doesn't seem to work.
[20:35:15] <kohsuke> OK, let's file that one separately
[20:36:40] <josb> kohsuke: it's supposedly covered by JENKINS-26834, but there seems to be an issue because it doesn't work, even though that issue has been marked Fixed.
[20:37:16] <kohsuke> I don't think it's covered by that issue
[20:37:30] <kohsuke> Jenkins core generally doesn't allow plugins or anyone to set the result to a better value than before
[20:37:36] <kohsuke> It only lets you set the result to a worse value
[20:38:02] <kohsuke> This is to prevent plugins from inadvertently masking an early failure
[20:38:19] <josb> kohsuke: I see, that actually makes some sense. Probably good to document that.
[20:40:46] <josb> kohsuke: even 'try { ... } catch(e) { ...}' doesn't help here because the build wrapped in the try still sets the internal state of the current build to FAILURE if the wrapped build fails. So the only solution is to use 'propagate: false'. To get the build state, once can use a handle and get the result on the handle.
[20:41:52] <josb> kohsuke: s,once,one,
[20:42:05] <kohsuke> josb: it's not the build() step that's marking the build as a failure, it's the catchError {...} step that's doing it
[20:42:14] <kohsuke> so if you replace it with try/catch, it will work
[20:42:30] <josb> kohsuke: let me try that (again).
[20:42:52] <kohsuke> josb: IIUC, in your case "propagate:false" seems cleaner
[20:44:37] <josb> kohsuke: I agree.
[20:45:53] <josb> kohsuke: unfortunately that doesn't work. If I wrap the job in a try ... finally and the job fails, the wrapping job also fails. That's what I am trying to avoid.
[20:46:15] <kohsuke> I need to test this
[20:46:59] <josb> kohsuke: but when I add the propagate: false, it works the way I want it to. I did expect the try ... finally to work and gobble up the failure (so I can rethrow it if needed), but it does not.
[20:47:26] <kohsuke> to me that's a bug
[20:48:43] <josb> kohsuke: http://pastebin.com/nmGHjmJv has the script.
[20:49:23] <josb> kohsuke: I agree.
[20:51:10] <kohsuke> public docker repo is incredibly slow
[20:51:26] <kohsuke> (trying to download the demo workflow environment)
[20:51:55] <josb> kohsuke: I would expect the try ... finally to hide the failure, so if I don't rethrow, the containing build succeeds despite the wrapped build failing.
[20:59:36] <josb> kohsuke: thanks again for your help looking into this. It's not urgent but it would be nice if it were fixed at some point.
[21:00:27] <kohsuke> josb: your script is try/finally
[21:00:30] <kohsuke> you are not catching the error
[21:00:53] <kohsuke> josb: it needs to be https://gist.github.com/kohsuke/49b77acceaa07e421a91
[21:06:44] <josb> kohsuke: Yes, your are right! You HAVE to catch the error. I didn't know that. Thanks for enlightening me. So there's no bug, but maybe the docs could make this clear.
[21:07:06] <kohsuke> yes, the doc in general for workflow is very high priority
[21:07:55] <josb> kohsuke: I was under the mistaken impression that just wrapping the build in a try block would be sufficient.
[21:07:56] <kohsuke> KostyaSha: the release went through
[21:08:47] <josb> kohsuke: but I'll stick with the propagate: false solution because it seems more localized and expresses intent better.
[21:08:47] <kohsuke> sorry, I don't understand
[21:08:53] <kohsuke> josb: +1
[21:09:53] <josb> kohsuke: thanks for Jenkins and the great training (I attended your class a while ago). Have to run. Bye!