CloudBees SDM in Action: How to Identify Unreviewed Pull-Requests Blocking Jira Issues

Written by: Sylvain Deyris

This post is the first of a series introducing how to use CloudBees SDM to solve real-life, daily problems faced by software teams. 

To start, I will examine a reoccurring task: identifying pull-requests that have not been reviewed across all the repositories contributing to my product and relating them with the Jira issue that could be delayed. Surfacing the Jira context around a pull-request helps determine which ones are the most important and take immediate action to improve overall product delivery efficiency. Delays in pull-request reviews and their impact on software delivery are the kind of statements you typically hear in a retrospective meeting or as a question you ask yourself as an engineering manager.

To tackle this project, I will leverage apps in CloudBees SDM, connecting my GitHub organization and my Jira project, and then utilize the query and tabular reporting capabilities. I will also assume my product is defined in CloudBees SDM and linked to the repositories contributing to it. My goal will be to retrieve all pull-requests on repositories belonging to my product that are open for more than two days, not yet reviewed and delivering a Jira issue. And obviously, I will want to build a report that I can reuse or share with my team so that everyone can get informed and take action.

To start, I navigate to the reports section of CloudBees SDM and start framing a query. I am mainly interested in the pull-requests that are late being reviewed, so I pick the “githubPullRequests” data type and start framing my query. As I am enriching the query, the smart type-ahead is proposing relevant data model fields in my current context and a result counter is letting me know the number of matching rows (or a red message explaining the error I made). I use the following tokens to frame my query to find pull-requests that are:

  • Belonging to a repository contributing to my product: repository.products.any(name='<MY PRODUCT NAME>')

  • Still Open (and not already merged or rejected): state = 'OPEN'

  • Open since more than 1 day (so that you could expect it has been reviewed already): createdAt < now('-1 day')

  • Not yet reviewed: pullRequestReviews.size() = 0

  • Delivering a Jira issues:  jiraIssues.size() > 0

Then, I define the data I need to take action. For each column, I specify its title and its content. In order to investigate a bit more or prioritize actions, we will use:

  • Pull-request name: title

  • Pull-request creation date: createdAt

  • Related issue key: jiraIssues.jiraIssueKey

  • Related issue name: jiraIssues.fields.summary

  • Related issue priority:

The last step is to name this report and save it so that I will be able to share it with my team.

This report will now be available in CloudBees SDM, constantly updated with the latest information. II will be able to access it regularly to monitor the situation and share it with my team so that we can rally around this goal of unblocking issues and take action.

I could add more fields to specify the action being taken, like surfacing the pull-request creator to give a heads up the pull-requests are sitting unreviewed or knowing if it is currently conflicting or not building to perform the required code fixes. I can refer to the documentation to get a full view on the query language and data model.

This first post was a basic introduction to the CloudBees SDM reporting and querying engine and some of the available data types, relations and operations available. I will share more details in upcoming posts about other exciting components we are building out, including analytics capabilities and a common data model shared by multiple tools.

And in the meantime, you can learn more about CloudBees SDM or join our preview program.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.