Our GitLab integration allows you to import merge requests, issues and associated comments, commits and reviews into Keypup to create unique metrics around these entities and across multiple projects.
Data coming from GitLab 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.
Note on security: we do not fetch your code. Keypup only retrieves metadata such as merge requests and issues and does not require access to the underlying code. See section below "What data do we collect?". |
What data do we collect ?
Our GitLab integration fetches the following entities:
Comments
This entity is exposed as a dataset on Keypup. Comments can be used to create a feed of updates or used to create activity metrics.
E.g. Recover and display comments of all recently pushed merge requests.
Commits
This entity is exposed as a dataset on Keypup. Only commits attached to merge 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 main/master these last two weeks.
Issues
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.
Labels
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 GitLab.
E.g. Retrieve only issues and pull requests which have the bug label.
Milestones
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.
Merge Requests
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 of open pull requests with less than 30 lines of code changed (“small” pull requests).
N.B. Keypup tends to use GitHub terminology. Merge requests are therefore commonly referenced as “Pull Requests”. |
Merge Request approvals
This entity is exposed as the Reviews dataset. It is also used to populate the review_state and required_approvals_remaining fields on the Issues & Pull Requests dataset. Note that GitLab does not have the concept of “rejected reviews'', therefore only approved reviews appear in the dataset.
It can be used to create metrics or listings.
E.g. List all recent approval reviews.
Merge Request build status
This entity is used to populate the build_status field on the Issues & Pull Requests dataset. It is only applicable to merge requests. It can be used to filter merge requests in metrics and listings.
E.g. Retrieve the list of merge requests that were merged with a failed build.
How often do we refresh data?
Updates from GitLab are received in real time via webhooks except for Labels and Milestones, which have to be long-polled from GitLab every 20 minutes.
If for any reason we are unable to set up real-time updates on GitLab - e.g. the user who connected GitLab has no admin access on a given project - then we revert to long polling data every 20 minutes.
Whenever possible we recommend connecting GitLab projects as an admin to get the best experience.
Improved reporting: Linking Issues to Merge Requests?
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.
How does it benefit my reporting?
Linking issues to merge requests allows us to populate and improve the following fields:
Issues & Pull Requests > Due on: When a merge request is linked to one or more issues, Keypup automatically infers the due date by taking the soonest of all due dates across the merge 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 merge requests. The field can have the following values:
None: the issue has no attached merge requests. It is not being implemented.
In progress: the issue has at least one open merge request attached to it.
Implemented: all attached merge requests are merged or closed.
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 merge request.
How to link issues to merge requests?
There are several ways to reference an issue from a merge request.
Option 1: Via the merge request title
To reference a JIRA issue such as PROJ-123 or a GitLab issue such as my-org/my-project#475 , you can set your merge request title to:
[PROJ-123] Resolve problem with login button
[my-org/my-project#475] Resolve problem with login button
Option 2: Via the merge request body or a commit message
You may also reference issues from the description of merge pull request or via commit messages using an auto-closing keyword such as fix, fixes, close, closes, resolve, and resolves, for instance:
This MR updates the handler attached to the login button. Fixes PROJ-123
Fix the login button. Closes https://myorg.atlassian.net/browse/PROJ-123
Fix the login. Closes my-org/my-project#475
This is a fix. Resolves https://gitlab.com/my-org/my-project#475