BaseDir / soruces path problem

[DanielBoettner]

Hello and thank your for your work on this.

I want to report an issues with a likely relation to #28 .

I have the following sonar-project.properties

sonar.projectKey=Foo
sonar.projectBaseDir=/var/www/html
sonar.sources=.
sonar.project.home=/var/www/html
sonar.php.tests.reportPath=/var/www/html/log/phpunit/logfile.xml
sonar.php.coverage.reportPaths=/var/www/html/log/phpunit/coverage.xml

The docker run command is

docker run -ti \
-v $(pwd):/var/www/html  \ 
-v $(pwd)/sonar-project.properties:/root/sonar-scanner/conf/sonar-scanner.properties \
--net proxy_default \
--workdir /var/www/html \
newtmitch/sonar-scanner

Which results in the error:

Project home must be an existing directory: /var/www/html/src

It seems for some reason the scanner always expects /src to be in the path.

In my attempt to find a working config.

I created an empty src directory in /var/www/html/ and and did set sonar.sources to ../
which starts the scan but ignores all files because they are not in the project directory.

... It is not located in project basedir '/var/www/html/src'

TL;DR

• I (currently) need the files to reside in /var/www/html because otherwise the scanner fails to parse the coverage.xml file. Which generates the paths with the absolute path
• When the docker container is started with the project put to /var/www/html/ and the sonar-project.properties reflect that, the scan fails because the scanner seems to expect src in the project path.

[newtmitch]

Hi @DanielBoettner - take a look at the latest images that I uploaded to Docker Hub a couple of days ago - there was a PR submitted by another user that moved from using /root for the working directory to using something less "drastic". I changed it to /usr/src. I'm going to try your run command here and see how this goes with a different project just to see if I can reproduce.

[newtmitch]

@DanielBoettner replicated the issue, kind of. Turns out the CMD line for the Dockerfile included sonar.projectBaseDir as /usr/src (per the latest update) or /root/src for you given the older image. My local run with your setup was also failing, albeit a bit less dramatically - just wasn't finding the files to process.

I wasn't following Docker best practices for using CMD or ENTRYPOINT commands in the Dockerfile, so I'm adjusting that and will be pushing up new images shortly after I update the README to discuss this approach. Once the images are updated, you can override the default sonar.projectBaseDir by including that as part of the docker run command. Using your command above as an example:

docker run -ti \
-v $(pwd):/var/www/html  \ 
-v $(pwd)/sonar-project.properties:/root/sonar-scanner/conf/sonar-scanner.properties \
--net proxy_default \
--workdir /var/www/html \
newtmitch/sonar-scanner -Dsonar.projectBaseDir=/var/www/html

Note that this is after I get the images updated, which might take me about an hour.

If you want to try it with the images you currently have, you can also override the entire CMD instruction included in the Dockerfile using this approach, which requires including the sonar-scanner command as well:

docker run -ti \
-v $(pwd):/var/www/html  \ 
-v $(pwd)/sonar-project.properties:/root/sonar-scanner/conf/sonar-scanner.properties \
--net proxy_default \
--workdir /var/www/html \
newtmitch/sonar-scanner sonar-scanner -Dsonar.projectBaseDir=/var/www/html

Let me know how this goes.

[newtmitch]

For future reference, Dockerfile ENTRYPOINT best practices: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#entrypoint

[albertocsm]

i dont want dispute what the best practice is in this regard but this[1] change potentially breaks Jenkins jobs with
ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).

most importantly, IMHO i dont think that overwriting existing docker image tags with this/any change is a good policy. if a new tag/version with the "fix" was pushed instead of overwriting existing ones, it would not break existing stuff (unless it relied on the latest tag)

anyway, let me take the chance to appreciate the work you are offering to the community here.
thank you!

[1] 71cce66

cc/ @newtmitch

[DanielBoettner]

@newtmitch thank you for your great work