Dataset: Issues & Pull Requests
Entity: Pull Requests, Issues
Field ID: recommended_action
Type: Select list
Description (Pull Requests): The action that Keypup recommends (e.g. review, merge etc.) based on the status of the pull request (approval status, build status etc.). Read more here.
ASSIGN_REVIEWER: The PR has not been updated in 3 days and has no reviewers assigned. The author may have finished their work and forgot to assign reviewers.ASSIGN_MISSING_REVIEWERS: The PR has less reviewers assigned than the number of required approvalsFIX_BUILD: The PR has its build failingFIX_CODE: The PR has one reviewer who requested changes on the codeMERGE: The PR is approved and has a green build. It is time to merge it.NONE: The PR is merged or closed. Also used as a fallback value when we couldn’t detect a useful recommendation.REBASE: The PR is conflicting with the base branch and must be updated (rebased)REVIEW: The PR is currently waiting for reviewers to perform their reviews, until one request changes or the number of approving reviews exceeds the number of required approvals.
Description (Issues): The action that Keypup recommends based on the status of the issue (implementation status, related pull requests etc.). Read more here.
CLOSE: The issue must be closed as ALL resolving pull requests have been merged or closed.IMPLEMENT: The Issue is open and has no resolving pull requests yet.WAIT_FOR_IMPLEMENTATION: The issue is resolved by one or several pull requests which are currently open (not merged or closed)
Source: Calculated
Transformation logic (Pull Requests): Evaluated based on the current review status, build status and implementation status of the pull request or issue. See the description for details about each recommendation. The order of precedence for PR recommendations is the following:
NONE(if item is merged or closed)REBASEFIX_BUILDASSIGN_MISSING_REVIEWERSREVIEWFIX_CODEMERGEASSIGN_REVIEWERNONE(fallback)
Transformation logic (Issues): Evaluated based on the current implementation status of the issue and its related pull requests. See the description for details about each recommendation. The order of precedence for issue recommendations is the following:
NONE(if the item is closed)WAIT_FOR_IMPLEMENTATIONCLOSEIMPLEMENTNONE(fallback)
From: |
|
Github (PRs, Issues) | N/A |
Gitlab (PRs, Issues) | N/A |
Bitbucket (PRs) | N/A |
JIRA (Issues) | N/A |
ClickUp (Issues) | N/A |
Trello (Issues) | N/A |
Extended logic
Recommended Actions On Pull Requests
The recommended action field is based on an industry standard stipulating that pull requests should broadly follow the lifecycle below:
A pull request gets opened and is actively worked on.
If left untouched for a few days and with no reviewers, it is likely that the author forgot to assign reviewers. Reviewers must therefore be assigned or active work must be resumed.
Before review, the pull request must be up to date with the base branch (no conflicts) and must have a green build - so reviewers review the final version of the pull request.
To be approved, a pull request must receive a minimum number of approvals. This minimum number of required approval(s) is set in each repository system (GitHub, GitLab, Bitbucket). Keypup always considers that each pull request should receive at least one approving review.
A reviewer rejection means the author of the pull request must perform additional work and request a re-review. This restarts the cycle to step (1).
Once a pull request is green on all three aspects (review, build and base branch), it can be merged.
Recommended Actions On Issues
The recommended action on issues is much simpler as teams have many different completion workflows. Keypup takes the assumption that issues will broadly follow this lifecycle:
An issue must be implemented by a pull request. The relationship between the issue and its pull request is discovered via auto-closing keywords.
When an issue is related to an open pull request, it is considered as being implemented.
When all pull requests related to an issue have been closed or merged, Keypup considers that the issue should get closed at some point - probably after following some QA and release process on your side.