Ok, that helps. Thanks again.
And for anyone searching the mailing list in the future, here's the
relevant bit for post build activity from the Pipeline Model Definition
plugin.
https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Notifications
On Mon, Nov 7, 2016 at 6:56 PM,
On Mon, Nov 7, 2016 at 4:23 PM, Tim Downey wrote:
> under pipeline,
> traditional Notifiers would not be used and instead flow control around
> build status should be inside of the pipeline as opposed to the plugin?
Right.
> also
> seems to require the most work for
Ok, so you're saying the convention would be that under pipeline,
traditional Notifiers would not be used and instead flow control around
build status should be inside of the pipeline as opposed to the plugin? In
other words, instead of having the flowdockNotifier() figure out what to do
based on
On Mon, Nov 7, 2016 at 2:26 PM, Tim Downey wrote:
> The issue is that run.getResult() is returning null even when used in a
> pipeline *after* which the build should have failed (e.g. after failing to
> pass unit tests or compilation). I'm wondering if there is
Hi Jesse,
I'm hoping you can point me in the right direction for one more thing. I'm
trying to understand at what point in the pipeline process does the build
result (via run.getResult()) become available? As you can see below, I'm
calling the original FlowdockNotifier code in a step
On Tue, Nov 1, 2016 at 2:04 PM, Tim Downey wrote:
>if(build.getProject().getRootProject() != build.getProject()) {
>projectName =
> build.getProject().getRootProject().getDisplayName();
>configuration = " on " +
Hi,
I'm working on updating the Flowdock plugin to support pipeline and am
getting hung up in how to map some of the old calls to the new API. In
general, I've gone through and replaced AbstractProject with Run.
I've got a few hangups that I was hoping that someone with direct
knowledge