-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.45
HipChat Plugin 2.1.0
When using HipChat v2 authentication tokens, the HipChat Plugin currently requires either a personal token, or a room-specific token to be stored within Jenkins. This means that you either have to accept all notifications coming from an existing user account (which costs a HipChat license), or you are constrained to using a single Room Notification token for each build job (which prevents you sending notifications to multiple rooms). Clearly you can revert to v1 API behaviour, but this prevents using the new Card notifications.
Ideally the HipChat plugin should install itself against HipChat using an Add-on generated token (see https://developer.atlassian.com/hipchat/guide/hipchat-rest-api/api-access-tokens). This could be installed against all rooms or single rooms within a HipChat instance. It would also remove the need for a specific user-account for notification messages.
[JENKINS-41976] Add support for Add-on generated HipChat v2 tokens
Ben Middleton
added a comment - Not quite. I'm not proposing adding support for Glances (although that's an interesting enhancement indeed). Instead, this issue is just to remove the need for a dedicated HipChat user for sending Jenkins notifications to multiple rooms (which a Room Notification token will not allow). Similar to how Jira and Confluence HipChat integrations send notifications to multiple HipChat rooms.
Ben Middleton
added a comment - Not quite. I'm not proposing adding support for Glances (although that's an interesting enhancement indeed). Instead, this issue is just to remove the need for a dedicated HipChat user for sending Jenkins notifications to multiple rooms (which a Room Notification token will not allow). Similar to how Jira and Confluence HipChat integrations send notifications to multiple HipChat rooms. I've been trying to read more about addons, but I always end up having the feeling that it requires having HTTP endpoints exposed by some means. I've summed up my questions here:
https://answers.atlassian.com/questions/53746531/
In general though: anything that will require an exposed endpoint (such as the capabilities descriptor), will most likely never make it into the plugin.
You may be able to create a BYO integration and save the obtained OAuth2 access token as a v2 credential to achieve your goals.
aldaris
added a comment - - edited I've been trying to read more about addons, but I always end up having the feeling that it requires having HTTP endpoints exposed by some means. I've summed up my questions here:
https://answers.atlassian.com/questions/53746531/
In general though: anything that will require an exposed endpoint (such as the capabilities descriptor), will most likely never make it into the plugin.
You may be able to create a BYO integration and save the obtained OAuth2 access token as a v2 credential to achieve your goals. Ben Middleton
added a comment - OK - thanks for investigating. That makes sense.
I'll see if I can create a BYO integration for this and report back.
Ben Middleton
added a comment - OK - thanks for investigating. That makes sense.
I'll see if I can create a BYO integration for this and report back. 
Sounds similar to https://github.com/jenkinsci/hipchat-plugin/issues/80