Our GitHub integration allows you to import pull requests, issues, and associated comments, commits, and reviews into Keypup to create unique metrics around these entities and across multiple projects.

Data coming from GitHub can be used to calculate overview metrics such as DORA metrics or to drill down on particular aspects of development, such as retrieving all pull requests currently requiring a peer review.

Our GitHub integration fetches the following entities:

This entity is exposed as a dataset on Keypup. Comments can be used to create a feed of updates or to create activity metrics.

E.g. Recover and display comments of all recently merged pull requests.

This entity is exposed as a dataset on Keypup. Only commits attached to pull requests are retrieved. Standalone commits pushed directly to branches are not available on Keypup at this stage. Commits can be used to create activity feeds, release notes, or metrics.

E.g. Display the commit message of all commits merged into the main/master branch over the last two weeks.

This entity is exposed on Keypup as part of the Issues & Pull Requests dataset. It can be used to create activity metrics.

E.g. Calculate the Mean Time To Closure on bugs or incidents.

This entity is exposed as a field on the Issues & Pull Requests dataset. It is used to refine metrics and queries based on labels used in GitHub.

E.g. Retrieve only issues and pull requests that have the “bug” label.

This entity is used to populate the due on field on the Issues & Pull Requests dataset. It is used to filter issues and pull requests based on their due date.

E.g. Retrieve all pull requests and issues which are currently overdue.

This entity is exposed on Keypup as part of the Issues & Pull Requests dataset. It can be used to create activity metrics.

E.g. Calculate a refactoring ratio, which is the number of lines of code deleted divided by the number of lines of code added.

It can also be used to create more simple listings:

E.g. List open pull requests with less than 30 lines of code changed (“small” pull requests).

This entity is used to populate the build status field on the Issues & Pull Requests dataset. It is only applicable to pull requests. It can be used to filter pull requests in metrics and listings.

E.g. Retrieve the list of pull requests that were merged with a failed build.

This entity is used to populate the reviewers, review state, required approvals, and required approvals remaining fields on the Issues & Pull Requests dataset. It is only applicable to pull requests. These fields can be used to filter pull requests in metrics and listing.

E.g. Retrieve the list of open pull requests still requiring a review.

This entity is used to populate the review fields above but is also exposed as a dataset on Keypup. It can be used to create metrics or listings.

E.g. Compare the proportion of approved reviews vs rejections or create a feed of review comments.

Updates from GitHub are received in real time via webhooks.

If we are unable to set up real-time updates from GitHub - e.g. the user who connected GitHub has no admin access on a given project - then we revert to long polling data every 20 minutes.

Whenever possible we recommend connecting GitHub projects as an admin to get the best experience on Keypup.

The duration depends on how many projects you connect and how much history you have in each project. You will be informed by email when the import is complete.

Keypup uses context inference and link detection to automatically enrich your data, add new fields, and simplify your reporting. Context inference can be improved by linking pull requests to issues using auto-closing keywords.

Linking issues to pull requests allows us to populate and improve the following fields:

Issues & Pull Requests > Due on: When a pull request is linked to one or more issues, Keypup automatically infers the due date by taking the soonest of all due dates across the pull request and its related issues.

Issues & Pull Requests > Resolution State: This field is only applicable to issues. It infers the implementation status of the issue by looking at the associated pull requests. The field can have the following values:

These two fields can be used to refine your metrics and/or drill down on specific data. E.g. Retrieve the list of overdue issues which - on top of that - are not being currently resolved by a pull request.

There are several ways to reference an issue from a pull request.

Option 1: Via the pull request title

To reference a JIRA issue such as PROJ-123 or a GitHub issue such as my-org/my-project#475 , you can set your pull request title to:

Option 2: Via the pull request body or a commit message

You may also reference issues from the description of your pull request or via commit messages using an auto-closing keyword such as fix, fixes, close, closes, resolve, and resolves, for instance:

Read this article to learn more about closing keywords and cross-references.

Please do not link issues to Pull Request via the Linked issues settings menu on the side of the Pull Request screen.

Issues linked this way are not exposed on the GitHub API. This means third-party applications will be unable to see these links, including Keypup.

Use closing keywords instead, as described in the previous section. Issues linked via closing keywords will still appear under the Linked issues setting menu.