Our Bitbucket integration allows you to import pull requests, issues, and associated comments, commits, events and reviews into Keypup to create unique metrics around these entities and across multiple projects.
Data coming from Bitbucket 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 pull requests and issues and does not require access to the underlying code. See the section below "What data do we collect?". |
What data do we collect?
Our Bitbucket integration fetches the following entities:
Activity Events
Activity events (e.g. created, closed, assigned, etc.) are fetched for each pull request and exposed in the Activity Events dataset.
These events are also used for the calculation of certain calculated timestamps such as assigned_at and last_assigned_at.
Comments
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.
Commits
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. Also due to limitations on the Bitbucket API, the number of lines added, and lines deleted are not retrieved for each commit - they will always appear as zero. 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 over the last two weeks.
Pull 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).
Pull Request build status
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.
Pull Request Reviews
This entity is exposed as the Reviews dataset. It is also used to populate the review_state and required_approval_remaining_count fields on the Issues & Pull Requests dataset. It can be used to create metrics or listings.
E.g. Compare the proportion of approved reviews vs rejections.
E.g. Create a feed of review comments.
How often do we refresh data?
Updates from Bitbucket are received in real-time via webhooks.
If for any reason we are unable to set up real-time updates on Bitbucket - e.g. the user who connected Bitbucket has no admin access on a given project - then we revert to long polling data every 20 minutes.
Whenever possible we recommend connecting Bitbucket projects as an admin to get the best experience.
Improved reporting: Linking Issues to Pull 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 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:
None: the issue has no attached pull requests. It is not being implemented.
In progress: the issue has at least one open pull request attached to it.
Implemented: all attached pull 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 pull request.
How to link issues to pull requests?
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 BitBucket issue such as my-org/my-project#475 , you can set your pull request title to:
[PROJ-123] Resolve problem with login button
[my-org/my-project#475] Resolve problem with login button
Option 2: Via the pull request body or a commit message
To do so the reference or URL of your issue must be prefixed by an auto-closing keyword, such as “fixes”, “resolves” or “closes” - for instance:
This PR updates the handler attached to the login button. Fixes PROJ-123
Fix 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://bitbucket/my-org/my-project#475