From the look at your commands, I guess you are not using our image as a single step, but instead using it as a base container for your pipeline or something like this. Basically I have the feeling you are skipping our entrypoint.
In this case, you have to either:
ensure the default working directory (./.scannerwork) can be written by the user 1000
change the working directory to a place where the user 1000 will have write permission
revert to root user if you are extending our image and this is not a security concern for you
I’m using it as a single step, it’s inside a cloudbuild ci but it only launches these commands and the entrypoint isn’t changed (at least it shouldn’t be)
So your solution would be to do our own custom image ? The problem is that, in this case, we’ll have to maintain it
yes : this is the sonar step inside the cloudbuild CI : It gets the vars from env vars
It’s set at true at the end to avoid blocking the CI if sonar fails
The problem is that you are using the script attribute, that will execute it inside our image, actually bypassing our entrypoint.
To use our image entrypoint, you should instead pass things as arguments.
On a side note, sonar.language is deprecated for years. Also, if you have a Maven or Gradle project, it would be better to scan it using our Maven or Gradle scanner directly.
Hi ,
Where you ran the clean runner caches commands? Can anyone please confirm??
I am using JenkinsX as CI-CD tool.
SonarScanner 5.0.1.3006
Java 17.0.11 Alpine (64-bit)
Linux 5.15.0-1041-azure amd64
SonarQube server 10.2.0.77647
Getting this error on pull request-
Error during SonarScanner execution
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘ClassRealm{javascript}-org.sonar.plugins.javascript.eslint.BridgeServerImpl’: Unsatisfied dependency expressed through constructor parameter 4; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘AnalysisTempFolder’ defined in org.sonar.scanner.analysis.AnalysisTempFolderProvider: Unsatisfied dependency expressed through method ‘provide’ parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘DefaultInputProject’ defined in org.sonar.scanner.scan.InputProjectProvider: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.api.batch.fs.internal.DefaultInputProject]: Factory method ‘provide’ threw exception; nested exception is java.lang.IllegalStateException: Fail to create working dir: /workspace/source/.scannerwork
Hi G Ann Campbell ,
I just wanted to understand in which image version of sonarscanner below issue got fixed:-
Error during SonarScanner execution
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘ClassRealm{javascript}-org.sonar.plugins.javascript.eslint.BridgeServerImpl’: Unsatisfied dependency expressed through constructor parameter 4; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘AnalysisTempFolder’ defined in org.sonar.scanner.analysis.AnalysisTempFolderProvider: Unsatisfied dependency expressed through method ‘provide’ parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘DefaultInputProject’ defined in org.sonar.scanner.scan.InputProjectProvider: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.api.batch.fs.internal.DefaultInputProject]: Factory method ‘provide’ threw exception; nested exception is java.lang.IllegalStateException: Fail to create working dir: /workspace/source/.scannerwork
GitLab has a Clear Cache button on their UI in the pipelines view.
I haven’t used JenkinsX, so I wouldn’t know where to look, but there could also be a similar button/mechanism for clearing your pipeline cache.
If there isn’t, it might be worth reading up on how your pipeline software stores cache, and subsequently how it can be modified/cleared in order to get your sonar job working again.
We’re not able to set -Dsonar.working.directory when running the latest sonar-scanner-cli docker image. Looks like the value is overridden from some default location and this directory needs to be accessible in our CI Jenkins workspace to evaluate Quality Gate status.
WARN: Property ‘sonar.working.directory’ with value ‘/sonar/.scannerwork’ is overridden with value ‘/tmp/.scannerwork’
NOTE: Downgrading to sonarsource/sonar-scanner-cli:5.0.1 works.