Running Sonar Scanner Inside of a Dockerfile, built via GitLab CI

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension): SonarQube Enterprise 9.9, dotnet-sonarscanner --version 6.0.0
  • what are you trying to achieve: Run a sonarscan inside of a dockerfile

Hi everyone,

I am trying to set up sonar analysis from within a dockerfile. I currently have this working on non containerised projects and this works perfectly.

I have the scanner running within a dockerfile and it is producing results to my SonarQube instance however I am struggling to get branch/MR configuration working.

SO far I have tried setting the and this works, however it means that merge requests are not detected and therefore the MR decoration is never shown.

I believe this is due to the required CI variables not being present in my dockerfile, so far I have added:

ARG CI_MERGE_REQUEST_SOURCE_BRANCH_NAME //sonar.pullrequest.branch
ARG CI_MERGE_REQUEST_IID //sonar.pullrequest.key
ARG CI_COMMIT_SHA //sonar.scm.revision

This has not seemed to work as analysis is put into the main branch in SonarQube. I have found in the logs the following:

INFO: Load project branches (done) | time=22ms
INFO: Load branch configuration
INFO: Load branch configuration (done) | time=2ms
INFO: Auto-configuring with CI 'Gitlab CI'

and in a scan not run in a dockerfile, I have the folowing logs:

INFO: Load project branches
INFO: Load project branches (done) | time=22ms
INFO: Load branch configuration
INFO: Detected branch/PR in 'GitLab'
INFO: Auto-configuring branch 'test/sonar'
INFO: Load branch configuration (done) | time=3ms
INFO: Auto-configuring with CI 'Gitlab CI'

so it appears I am still missing something to detect the branch.

Any advice on which CI variables are required would be appreciated. I understand that the implementation is internal and may change at any time but help would still be appreciated regardless


The fact that it’s an MR or branch should be being picked up automatically from the environment. So this is likely a question of your checkout. How are you doing that, and are you analysing in/from the same directory you checked out to?


As I mentioned, the analysis is being done within a Dockerfile, so the environment variables that the scanner would normally pick up for detection are not present unless they are passed in. this is the question i am asking, how can I find out which variables need to be passed in. My checkout is a full clone with depth set to 1000, I have manually verified this and the entire repo’s history is present all the way back to the initial commit


Just set the anlaysis parameters explicitly.


Doing this removes the automatic configuration which is a nice convenience to have. Otherwise I have to decide myself whether this is a merge request, or normal branch run and which branch etc.

Sonar scanner clearly pulls this information from the environment. I am just asking to know which variables in particular it is looking ag


Since the point is to make it “just work”, we’ve never seen the need to document those.


Yes I gathered that. However in this case, it doesn’t “just work” due to the environment not being the same. I will work it out eventually but I’d rather not have to manually work it out by adding every single GitLab CI variable and then removing them one by one until I have the minimum required set.

I have seen previous answers before with the variables needed listed, but this was an old post and it appears to no longer be the same, at least, I couldn’t make it work with these variables.

I have the same requirement, but for GitHub Actions, not GitLab. By process of elimination starting with every single GitHub environment variable, I eventually managed to get the required environment variables to pass through to the Docker container down to be just the following - with these auto branch detection was functional in both branch and PR pipelines:


It would be really helpful if these could be documented for each of the most common CI tools, rather than us having to figure it out ourselves.

1 Like