Skip to main content
All CollectionsData & operationsIssues & Pull Requests dataset
Issues and PRs > Resolved Issue IDs (System)
Issues and PRs > Resolved Issue IDs (System)
Tom Williams avatar
Written by Tom Williams
Updated over 3 months ago

Dataset: Issues & Pull Requests

Entity: Pull Requests

Field ID: resolved_issue_sysids

Type: List of text values

Description: The list of issue System IDs (Keypup IDs) that the pull request resolves via auto-closing keywords.

  • count the number of resolved issues on each pull request.

  • see a list of resolving Pull Requests from a specific issue by configuring a drilldown report on the resulting values (select all resolving Pull Requests where resolved issue ids contain the selected issue id).

Source: Calculated

Transformation logic:

  • Pull Requests: The list of system IDs (Keypup-generated IDs) from issues that are resolved by the pull request. Resolved issues are issues that are referenced by a pull request via auto-closing keywords.

  • Issues: This field will always be an empty array (an issue cannot be resolved by another issue)

Definition of resolving pull requests:

A resolving pull request is a pull request that:

  • Contains an auto-closing keyword to an issue

  • Has a state equal to OPEN or MERGED, not CLOSED

  • Has a base ref that has not been used as a head 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

Gitlab

Bitbucket

JIRA

N/A

ClickUp

N/A

Trello

N/A

Did this answer your question?