Dataset: Issues & Pull Requests
Entity: Pull Requests
Field ID: resolved_issue_metatags
Type: List of text values
Description: The combination of metatags from all resolved issues (via auto-closing keywords), deduplicated and sorted. It is only applicable to pull requests.
Issue metatags combine the labels and sub-types (e.g. Jira issue type) of issues. This field is useful to simplify filtering, especially when creating dashboard-wide filters.
Source: Calculated
Transformation logic:
Pull Requests: Aggregate all results from the
metatags
field of issues that are resolved by the pull request. Metatags are sorted and deduplicated for consistency reasons. Resolved issues are issues that are referenced by a pull request via auto-closing keywords.Issues: Not applicable. This field will always be an empty array
[]
.
โ
Definition of resolved issues:
A resolved issue is an issue that is referenced by a resolving pull request.
A resolving pull request is a pull request that:
Contains an auto-closing keyword to an issue
Has a
state
equal toOPEN
orMERGED
, notCLOSED
Has a
base ref
that has not been used as ahead ref
by a previous pull request associated with the issue
This last condition ensures that release PRs (e.g. PR from master
to staging
then staging
to production
) do not get considered as resolving if they follow a proper implementation PR (e.g. from my-feature-branch
to master
), even though they contain references to issues through commits.
This condition replaces the rule from GitHub, GitLab, and Bitbucket that resolving pull requests must target the main branch. This condition is not practical for Keypup since the main branch can change over time. Using this definition would mean that any resolving PR preceding a change of main branch would no longer be considered as resolving, which would impact historical reporting.
The Keypup definition also brings some flexibility in case of emergency releases. If you push an emergency fix referencing an issue to the main branch and then release this fix through release PRs, then the first release PR will be considered as a resolving PR (GitHub/GitLab/Bitbucket would simply ignore it). This information can then be used for incident reporting in Keypup.
From: |
|
Github (PRs) | Inferred from GitHub auto-closing keywords |
Gitlab (PRs) | Inferred from GitLab auto-closing keywords |
Bitbucket | Inferred from Bitbucket auto-closing keywords |
JIRA | N/A |
ClickUp | N/A |
Trello | N/A |