Skip to end of metadata
Go to start of metadata

Plugin Information

View Pipeline GitHub Notify Step on the plugin site for more information.

This step allows a pipeline job to notify a status for any GitHub commit.

Intended for jobs that want to notify GitHub of any desired event with complete control over the notification content. Including context, status or target url.

Introduction

This plugin provides the githubnotify build step, this step can be used to create a status in Github.

The available parameters are:

  • credentialsId: The id of the github's credentials to use, must be of type UsernameAndPassword. Make sure the credentials have write access, as stated by doc Users with push access can create commit statuses for a given ref
  • status: The status to send, one of SUCCESS, FAILURE, ERROR or PENDING
  • description: The description that will appear at the notification
  • context: The notifications context, GH uses the context to diferentiate notifications (optional, jenkins/githubnotify is used by default)
  • sha: The sha that identifies the commit to notify status
  • repo: The repo that ows the commit we want to notify
  • account: The account that owns the repository
  • gitApiUrl: GitHub's Enterprise instance API url (optional, https://api.github.com is used by default)
  • targetUrl: The targetUrl for the notification

    githubNotify account: 'raul-arabaolaza', context: 'Final Test', credentialsId: 'raul-github',
        description: 'This is an example', repo: 'acceptance-test-harness', sha: '0b5936eb903d439ac0c0bf84940d73128d5e9487'
        , status: 'SUCCESS', targetUrl: 'http://www.cloudbees.com'

    Aditionally the step is able to infer most of this data when running from a pipeline multibranch job, in that the call is greatly simplified:

githubNotify context: 'Notification key', description: 'This is a shorted example',  status: 'SUCCESS'

Please go to the README of the plugin to find more details about how the inferring process works and when you cann use it 

Changelog

Version 1.0.3 (2017-08-16)

  • JENKINS-43370 The step now is able to use a proxy if defined. (Thanks to Markus Heberling for the fix)

Version 1.0.2 (2016-04-09)

  • JENKINS-42955 The step now uses the scan credentials over the checkout credentials for inferring

Version 1.0.1 (2016-12-24)

  • JENKINS-40422 The step now uses the scan credentials over the checkout credentials for inferring

Version 1.0.0 (2016-11-30)

  • Initial version

1 Comment

  1. This looks great.  However,  I don't completely understand how it would interact with the status notifications generated by the Github multibranch plugin.

    I assume that steps should be wrapped in `try{}' blocks with Githubnotify calls made in the  'catch{}` blocks for errors.  But then I'd expect the GitHub multi multibranch to think everything is good and sending another status update.  

    A working, simple Jenkinsfile of this use case (multibranch plugin) would be very useful.