A Jenkins plugin that sends notifications to HipChat chat rooms for build events.
The plugin allows two levels of configuration, each explained in the below sections. The assumption should be that if a project level setting can not be found, the plugin will fall back to the global configuration.
These settings can be found under Manage Jenkins -> Configure System and look for Global HipChat Notifier Settings. The settings listed here are:
To set up the plugin for an individual job, go to the job's configuration page and add the HipChat Notifications post-build action. The settings listed there are:
The message templates used by the plugin now fully support token-macro tokens, for a comprehensive list of the available tokens, please check out the help texts for the message template settings.
In addition to the out of the box supported tokens from the token-macro-plugin, the plugin can also utilize various other tokens provided by other plugins. Having the email-ext-plugin installed on Jenkins will make the following (non-comprehensive list of) tokens available for example:
If you find that one of the above listed tokens do not work with the plugin, you should probably check first whether the email-ext-plugin is installed on your Jenkins instance. The same rule applies for other third party token provider plugins.
The HipChat plugin also provides the following token implementations:
| Token name | Content | Example value |
|---|---|---|
| BLUE_OCEAN_URL | Blue Ocean UI friendly link to the currently built job | http://localhost:8080/jenkins/job/foobar/1/display/redirect |
| BUILD_DESCRIPTION | The description of the current build | Example build description |
| BUILD_DURATION | The duration of the build in human readable format | 42 min |
| COMMIT_MESSAGE | The first line of the last changeset's commit message | Initial commit |
| HIPCHAT_CHANGES | Human readable details of the new changesets or "No changes" if changesets weren't computed for this build | Started by changes from bjensen (1 file(s) changed) |
| HIPCHAT_CHANGES_OR_CAUSE | Returns HIPCHAT_CHANGES if it was successfully calculated, otherwise returns the cause of the build | Started by user Admin |
| TEST_REPORT_URL | Direct link to the test reports | http://localhost:8080/jenkins/job/foobar/1/testReport |
The plugin utilizes the proxy configuration in Jenkins when making external HTTPS connections. To configure proxy in Jenkins, follow the Jenkins documentation.
The currently supported features are:
When using pipeline projects, HipChat messages can be sent using the following DSL:
hipchatSend color: 'YELLOW', credentialId: 'myid', failOnError: true, message: 'test', notify: true, room: 'Jenkins', sendAs: 'Jenkins', server: 'api.hipchat.com', textFormat: true, v2enabled: trueNote that the following parameters for the hipchatSend step are planned to be deprecated in the next major version:
HipChat supports various kinds of cards for its notifications, as such the card implementation in the Jenkins HipChat plugin has been done in a pluggable manner. In case the out of the box available card implementations do not fit your needs, the following extension will need to be written:
@Extension
public class MyCoolCardProvider extends CardProvider {
private static final Logger LOGGER = Logger.getLogger(MyCoolCardProvider.class.getName());
@Override
public Card getCard(Run<?, ?> run, TaskListener taskListener, Icon icon, String message) {
// implement magic
}
@Override
public CardProviderDescriptor getDescriptor() {
return new DescriptorImpl();
}
@Extension
public static class DescriptorImpl extends CardProviderDescriptor {
@Override
public String getDisplayName() {
return "My cool card provider";
}
}
}The return value type Card represents a HipChat card and exposes all of its available properties as it is defined in the HipChat API documentation.
The idea behind the extensible approach is that lots of different card implementations can be made available. If you do end up writing a custom CardProvider, please open a pull request, so that others can benefit from it too. Having these custom implementations contributed should also ensure (to a reasonable degree) that future API changes will be reflected on these implementations as the changes are being made.