Setup of GitHub Webhooks
With the New York release we have also release a spoke for GitHub. This spoke comes with the functionality to subscribe to events happening in GitHub – like commits or pull requests. In this blog post I want to show you how to setup the integration between GitHub and ServiceNow and what you can do with these events. If you have comments or additional ideas on processes which can help a developer flow, please comment below.
Scenarios covered in this blog:
- Use commit comments to relate back to stories in Agile Development
Possible scenarios of a production setup:
- Update application version on completion of Pull Requests
- Link Commits back to your Agile Dev / SAFe stories
- Trigger notifications to development / testing team
- ...
Let’s start with the setup….
Get GitHub Spoke
You will need Integration Hub Standard activated in your instance to use these features. For more information, see Request IntegrationHub.
Visit the ServiceNow Store website to view all the available apps and for information about submitting requests to the store.
Configure Webhook in ServiceNow
Once the spoke is installed, we need to register our webhook and allow GitHub to talk to it. The spoke adds a new application ‘GitHub Webhooks’ to your navigator. Use the ‘GitHub Webhook Registries’ to create a new entry. I just named my webhook ‘My GitHub Webhook. You can create as many webhooks as you want, basically you would need a webhook defined per git-system you want to talk to. You could also define one per repository or user, but this is not required.
The platform will default a webhook path as of api/sn_github_spoke/github_webhook_callbacks/wh_entry.
Once you have saved this record there will be a UI Action ‘Callback URL’. Click it to generate the URL and Secret we need for Github and display them in Info-Messages.
Note: We do not see this record as configuration data and hence it will not land in your update set / source control. You will need to create the webhooks in every instance manually.
Configure Webhook in GitHub
For reference : GitHub documentation
Navigate to your repository where you want to receive the events. Choose the Settings tab on the far right, one of the modules here is ‘Webhooks’, click ‘Add Webhook’ – you might be asked to confirm your credentials.
Complete the form with the information we got in the previous step in ServiceNow.
Payload URL: https://<instance>.service-now.com/api/sn_github_spoke/github_webhook_callbacks/wh_entry?ni.nolog.id=<sys_id>
Content type: application/json
Secret: <the secret from servicenow>
SSL verification: enable SSL verification
Which events would you like to trigger this webhook?
Select the events you are interested in; in this example I will use ‘Pushes’.
Consume Event in ServiceNow
Note: Before we start on this think about where you want the following artifacts being created. I would recommend creating a bespoke scope for it and not add it to our ServiceNow GitHub Spoke.
Now that git will send us the events, we need to let ServiceNow know what to do with these. All processing is handled by sub flows. The Spoke delivers a set of sub flows as samples for you to amend. All these flows are named ‘Process GitHub ….’. You can find the list of flows and supported events on our docs page.
Let’s create our flow to handle Push/Commit events...
Create new sub flow
Open Flow Designer and find the sample sub flow ‘Process GitHub Push Webhook Events’. The sample flow will do a simple log message only. Create a copy to modify it to your needs. In this example we will iterate through all commit elements of the input and attempt to match the first 11 characters of a story number - if found update the story with the commit information.
Create dispatch rule
In order to dispatch the incoming event to the appropriate flow we use the module ‘GitHub Webhook Routing Policies’. Let’s setup two policies for our scenarios above.
Commit comments
Label: Commit comments
Condition : Webhook Event IS Push
Answer: Choose the flow you have created before, ‘Process GitHub Push Webhook Events (relate to story)’
Test
Now let’s commit some changes to our repository and wait for the Webhook to return the information. If all is setup correctly your story will be updated similarly to this one:
Summary
So basically with no code - maybe low code if you want a more sophisticated parsing of the event payload - we are able to get events incl. information back into ServiceNow and can leverage that in our development flows. I am interested to see what your comments, questions or even just the use cases are that you are or want to use this feature.
7 Comments
