+1

+1

+1

+1

+1

+1  & link to a stackoverflow question about just that.

It's a bit sad you have to call obscure shell scripts from your Jenkinsfile to use Jabber again instead of using this fine plugin.

+1

I started working on this feature, and it requires 2 PRs (im and jabber plugins). I'll open them once the code is ready to merge.

changes for Instant Messaging 
changes for Jabber

Direct links to branches if you want to build this manually:

https://github.com/akomakom/instant-messaging-plugin/tree/pipeline-support

https://github.com/akomakom/jabber-plugin/tree/pipeline-support

I am introducing a jabberNotify step: 

//pipeline: 
jabberNotify targets: '*test'

//normal options can be set:
jabberNotify notificationStrategy: 'failure', notifyCulprits: true, notifyFixers: true, notifySuspects: true, notifyUpstreamCommitters: true, targets: '*test'

//plus some extras:
jabberNotify extraMessage: 'I am the tester!', targets: '*test'

 In "test" Jabber chatroom (Result is NOT BUILT because the job hasn't finished and result hasn't been set):

[17:49:03] <Jenkins> Project test-pipeline-syntax build #70: NOT BUILT in 0.22 sec: http://xxxxxx I am the tester!!!

 I'm basically aiming to make a pipeline step that causes a "notify now" type action, disregarding concepts like "notify on start/end" that would only be possible in a FreestyleJob, but honoring things like "only culprits", "strategy", etc.  So the step code will probably wind up in either catch or finally blocks in real life most of the time (but it can be used multiple times in a build).

Without a doubt I'm not doing everything the best way, but I'll try to build on this over time.  Comments and PR's (to my branches, I guess) are welcome.

 Syntax generator screenshot:

I would suggest if possible to make a imnotify step instead so it's the same for all instant messages.

I'm far from an expert on this architecture, but I don't believe that this would be easy to do since currently the concrete implementations depend on instant-messaging.  They would have to register themselves somehow and since each one essentially designs its own UI for settings, this may be more difficult to juggle.

What's the advantage?

flow Did you assign this to yourself because you're stepping up as maintainer of instant-messaging?  It looks like kutzi is no longer actively involved.  If not... then who? kktest4? (I ask because my PR has not seen much activity)

I'd volunteer but I don't feel that I have enough knowledge to make architectural decisions without guidance.

The advantage is its the standard way of doing stuff in jenkins and it currently works that way for non pipeline. I actually had a brief look at one stage. But converting existing stuff to pipeline support is generally just changing the expected types of functions and adding if statements where it requires something not available as part of the common base of workflow and standard jobs

Is this available for installation?

kford2000, there has been no response from the maintainers to my 2 Pull Requests, so they have not been merged.

You can check out my two branches (linked from my original post) and build them, and you'll have the two plugins you need to get this functionality. (IM and Jabber plugins)

Can you share a sample pipeline

kford2000 see screenshot of the pipeline generator.  Once you are using the plugins you can do the same.

If you mean overall structure, it will depend on what you are doing.

Eg: notify that relies on build status, failure and fixed:

try {
  some work
  currentBuild.result = Result.SUCCESS.toString()
} catch {
  currentBuild.result = Result.FAILURE.toString()
} finally {
  jabberNotify notificationStrategy: 'failure and fixed', notifyCulprits: true, notifySuspects: true, targets: '*somechat'
}

but if you just want to do an arbitrary notification, it's a one-liner.

Please review and (hopefully) accept the Pull-Requests, as this functionality is essential for working with Pipelines and there are no efficient workarounds (at least on Windows environments).

As far as I can tell, there are no pull requests open.

flow, I'm guessing that you own Jabber but not Instant Messaging.

I have two branches, one for each, and I can't open the PR for Jabber until the PR for IM is merged.  I don't know if anyone owns that plugin, and I don't feel qualified to take it over and make executive decisions about its architecture.  Thus we're deadlocked.

flow, I'm guessing that you own Jabber but not Instant Messaging.

That is unfortunately the current situation.

I have two branches, one for each, and I can't open the PR for Jabber until the PR for IM is merged.

Please also open the PR against the jabber-plugin with a reference to this bug and a note that it requires the instant-messaging-plugin PR to be applied first.

I don't know if anyone owns that plugin, and I don't feel qualified to take it over and make executive decisions about its architecture.  Thus we're deadlocked.

Kutzi is AFAIKT the maintainer for the instant-messaging-plugin. I don't now if the is still active. I'll possibly try to claim maintainership for the instant-messaging-plugin too, like I did with the jabber-plugin, if no one else steps up.

flow could you please try to take stewardship of the IM Plugin? I'd love to see the pipeline PRs finally merged.

Hi,

Is there anything that I can do to help move this along?  I'm migrating quite a few jobs from freestyle to pipelines and I would hate to lose this functionality.

so flow should follow up with the merge of https://github.com/jenkinsci/jabber-plugin/pull/18

That PR has conflicts that you need to resolve first.

> That PR has conflicts that you need to resolve first.

Unfortunately I am not the author nor committer there. I think in github the repo maintainer may by default edit the source branch of a PR, in the other developer's repository.
Given that the conflict is just something in "versions.gradle", can you please see if it is something you may and can fix easily?

Will fix, just returning from vacation.

FYI, the jabber PR no longer has conflicts, but I suspect that it should be updated to depend on a stable version of the instant messaging plugin once it is released with the changes. It's not clear to me whether the SNAPSHOT version is even published in the wild.

Thanks. I was trying to make a release yesterday, but it stumbled on older dependencies first and on newly caught findbugs then, so stalled a bit ;(

No rush on my part.
Also, our team switched to Mattermost since I pushed this, so this will probably be my only PR for the foreseeable future.

I performed a release 1.37 of the instant-messaging-plugin so hopefully in a few hours its artifacts will be published and be dependable upon.

Also, you could endeavour to make a plugin to notify/bot/... via Mattermost, right?

Sounds good jimklimov.

Mattermost already has a plugin that does not depend on instant-messaging and has pipeline support: https://jenkins.io/doc/pipeline/steps/mattermost/