Pull Request Analysis in GitLab without using detached pipeline ("only: merge_requests")

SonarQube
, ,
1

Must-share information (formatted with Markdown):

  • SonarQube Developer 8.9.6, Scanner 4.6
  • Trying to achieve: Get a pull request analysis without using GitLab’s “Pipelines for Merge Requests” aka detached pipelines aka “only: merge_requests”.
  • Tried so far: Given parameters: sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base manually.

I’m trying to get a pull request analysis instead of a branch analysis. When using “only: merge_requests” in the .gitlab-ci.yml file, everything works as expected and the pull request appears in SonarQube under “Pull Requests”.

However, when I remove the “only: merge_requests” and give the three parameters sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base, the analysis is started using a branch analysis.

I don’t want to use pipelines for merge requests (“only: merge_requests”), because it conflicts with other GitLab CI stages/processes. What hidden variables does “only: merge_requests” set so that the analysis is started as a pull request?

Thanks.

2

Hi, SonarQube reads a bunch of “only: merge_requests” specific environment variables:

  • CI_MERGE_REQUEST_IID (Mandatory to trigger a MR decoration)
  • CI_MERGE_REQUEST_SOURCE_BRANCH_NAME (Mandatory to trigger a MR decoration)
  • CI_MERGE_REQUEST_TARGET_BRANCH_NAME (Optional, will use the main branch as default)
  • CI_MERGE_REQUEST_PROJECT_URL (Required to have the link to the MR from SQ PR view)
    (+ others environment variable not specific to only: merge_requests)

Keep in mind that its internal implementation, quite specific, and if you choose to “cheat” by providing these env variables yourself, things might break in the future without notice (=when the implementation change).

About the “conflicts with other GitLab CI stages/processes”, do you want to elaborate? Anything we can do on SQ side to ease the pain?

3

Unfortunately, this doesn’t work.

Even when specifying the aforementioned four environment variables manually, the analysis pops up as a “branch analysis” and not a “pull request analysis”.

4

Hi, I have a similar issue. My problem is that the detached sonarqube pipeline is the one that’s shown on the merge request page. I wanted the status of the main pipeline to be displayed instead of the detached pipeline.

5

From my understanding, Gitlab CI run merge requests pipelines as detached. The SonarQube analysis needs to run on the merge request pipeline, otherwise, we would not have the correct version of the code. So I’m not sure to understand what we could change on SQ side to accommodate this pain point.

6

Thanks Pierre. I just ran the rest of the main pipeline as merge request pipeline as well, and all is well in our project :slight_smile: