Issues with "Short-lived branches" vs. "Pull Requests"

We recently upgraded to SonarQube 7.9.1. We’ve been using short-lived branches for our pull request scans. I’m using some REST api calls to get information about projects, using the “/api/measures/component” operation with “component” and “branch” parameters.

We’re starting to test creating “Pull Request” projects. Someone else is working on the code for that. When we view the project in SonarQube, we see a branch name like " 58 – …" where “…” is the original branch name. The “58” is the pull request id. When I send the REST query providing the original branch name, I get an error saying “Component ‘…’ on branch ‘…’ not found”. It seems like the branch name in SonarQube has that prefix of the pull request id. However, I was unable to get the REST call to work with a branch name that matches what I see in SonarQube. What’s even odder is that the separator between the number and the original branch name is not an ascii “-”. It seems like a unicode character or something.

I’m not sure how to move forward here.

For a pull request, you should use the pullRequest query parameter set to the ID (integer) of the pull request!

Curious. The “pullRequest” parameter is marked “internal”. The only way to get information on a pull request is to use a non-public api?

I did verify that setting the “pullRequest” parameter INSTEAD of the “branch” parameter gets the data I need to see.

If I were to use this, I imagine it’s possible I might be seeing projects that are either short-lived branches or pullRequests, so I’d have to potentially run two requests to get the data. Is there an api that would tell me beforehand whether a project is a short-lived branch or a pull request?

I can see that long-term, the pull request makes more sense, and I believe Ann stated that version 8 deprecates (removes?) short-lived branches, so we’re obviously going to move in that direction.

I want to make sure the question at the beginning of my last post stands out. You’re advising me to use the “pullRequest” query parameter, but I see that this parameter is marked as “internal”. Is that an accident, or does that imply that this “pullRequest” mechanism is still preliminary and not final?

I’m not really advising you to do anything, I’m not even sure what exactly you use it for. :slight_smile: But if you’re looking for data on Pull Requests, the pullRequest parameter is the way to go.

Internal APIs are subject to change between versions without much fanfare about deprecation / announcing changes. We also (at one point in the past) tended to mark APIs as internal if they only related to features present in commercial editions of SonarQube.

  • You are using an LTS version of SonarQube, so if you stick to that release cadence you don’t have to worry about it for another year :slight_smile:
  • The pullRequest query parameter is probably safe. Pull Request IDs aren’t going away anytime soon. That said… our butts are covered if something changes (it’s marked internal!)

One other note:

Projects cannot be short-lived branches or pull requests, a SonaraQube project has short-lived branches and pull requests. You can think of the SonarQube project as the entire repository, and short-lived branches and pull requests being subsets of that repository. One project might have both! api/project_branches and api/project_pull_requests domains of Web APIs will give you more information for a single project.

1 Like