SonarQube Community Edition Version 9.9.4 (build 87374) (docker)
Using Sonar Scanner CLI (sonarsource/sonar-scanner-cli:latest) which is the latest v10 we are no longer able to set sonar.working.directory in our Jenkins Pipelines. Even if we set the parameter sonar.working.directory to e.g. /sonar/.scannerwork it gets overridden with /tmp/.scannerwork.
WARN: Property ‘sonar.working.directory’ with value ‘/sonar/.scannerwork’ is overridden with value ‘/tmp/.scannerwork’
The .scannerwork directory needs to be available in each Jenkins workspace for Quality Gate to be resolved for each job. In this case we volume mount the Jenkins workspace into /sonar path in the sonar-scanner-cli container.
Downgrading to sonarsource/sonar-scanner-cli:5.0.1 works as intended.
See this thread for further information and related change that broke this behaviour:
Please suggest workaround if setting sonar.working.directory no longer is supported in this way.
I’m asking because it might be just as easy to start using sonar.qualitygate.wait in your pipeline and avoid the working directory question altogether.
Testing sonar.qualitygate.wait with sonar-scanner-cli it works with v5.0.1 but when running the latest sonar-scanner-cli container (v10) it fails to start because of lack of permissions for /tmp directory.
We run the sonar-scanner-cli container with non-priv Jenkins node user (id -u:id -g) and would like to avoid a scenario where we have workspace file/folder user permission discrepancies and having to volume mount multiple paths for the container to function, and as mentioned previously it doesn’t work to override the working dir with the latest container image version.
If we volume mount the /tmp directory from the Jenkins host node into /tmp in the container it works but I’m not sure what kind of impact (if any) this will have at scale when running multiple builds with shared /tmp as sonar working directory.
If we are able to override and set the sonar.working.directory for the container we could just use the same directory as the workspace (like before) and avoid this situation.
WARN: Property 'sonar.working.directory' with value '/sonar/.scannerwork' is overridden with value '/tmp/.scannerwork'
...
11:03:14.649 INFO: Working dir: /tmp/.scannerwork
11:03:14.649 DEBUG: Project global encoding: UTF-8, default locale: en_US
11:03:14.666 INFO: ------------------------------------------------------------------------
11:03:14.667 INFO: EXECUTION FAILURE
11:03:14.667 INFO: ------------------------------------------------------------------------
11:03:14.667 INFO: Total time: 3.398s
11:03:14.706 INFO: Final Memory: 13M/68M
11:03:14.706 INFO: ------------------------------------------------------------------------
11:03:14.706 ERROR: Error during SonarScanner execution
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'ClassRealm{javascript}-org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl': Unsatisfied dependency expressed through constructor parameter 4; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'AnalysisTempFolder' defined in org.sonar.scanner.analysis.AnalysisTempFolderProvider: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.api.utils.TempFolder]: Factory method 'provide' threw exception; nested exception is java.lang.IllegalStateException: Unable to create root temp directory /tmp/.scannerwork/.sonartmp
We spent time to investigate and find the route cause of the issue. I can confirm that this is a bug. We will try to address with the upcoming scanner v6 updates. I will inform you after the bugfix is released.