-
Bug
-
Resolution: Fixed
-
Minor
-
None
When using Sonar Qube plugin set to install automatically, the execution fails inside of a Docker slave.
Possible workaround is manual installation but it would be nice if this was handled automatically like on bare metal slaves.
- is related to
-
-
- Reopened
-
[JENKINS-29410] Compatibility with Sonar plugin (and possibly other auto installed software)
Michael Süß
added a comment - It is not really practical to have separate images for all different combinations of build tools, package managers and runtime environments. We currently have several hundred build jobs of different projects on our build environment, that have different requirements on particular tool versions.
We want to use the auto-installer of Jenkins where possible and only have job or project specific images on special cases (there will still be a couple of them). Our main intention of using this plugin is to provide an isolated build environment for each build job and still be able to solve the issue of providing project specific environment adjustments on our build nodes.
Therefore I would like to see a higher priority on this issue.
Michael Süß
added a comment - It is not really practical to have separate images for all different combinations of build tools, package managers and runtime environments. We currently have several hundred build jobs of different projects on our build environment, that have different requirements on particular tool versions.
We want to use the auto-installer of Jenkins where possible and only have job or project specific images on special cases (there will still be a couple of them). Our main intention of using this plugin is to provide an isolated build environment for each build job and still be able to solve the issue of providing project specific environment adjustments on our build nodes.
Therefore I would like to see a higher priority on this issue. Plugin especially has been designed for such use case, so each team can provide a Dockerfile and define the exact set of tools and version it needs to build. Also, ToolInstallers would then have to run on every build, as the resulting changes in docker container would not be persisted - or have to tweak the toolinstaller so it installs within workspace.
That being said, having toolinstallers to work nicely with this plugin makes sense, need to investigate further how to hack the tool installation path. You're welcome to contribute if you want to see this issue fixed 
Andreas Mandel
added a comment - My use case is a bit different - I would use the docker container as a isolation sandbox for the different builds, while still maintaining a clean - minimum dependencies environment. Therefore it wold make sense to mount the hosts' tools directory into the docker container (if the tools allow in ro mode). But this would still leave other topics open.
Might be my requirement needs a different approach?
Andreas Mandel
added a comment - My use case is a bit different - I would use the docker container as a isolation sandbox for the different builds, while still maintaining a clean - minimum dependencies environment. Therefore it wold make sense to mount the hosts' tools directory into the docker container (if the tools allow in ro mode). But this would still leave other topics open.
Might be my requirement needs a different approach? Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/com/cloudbees/jenkins/plugins/docker_build_env/DockerBuildWrapper.java
http://jenkins-ci.org/commit/docker-custom-build-environment-plugin/1ee9e89ee11d1052289ba528bd72431efd5cb910
Log:
JENKINS-29410 bind mount tool installers directory
an issue remain, as we can't amend the PATH defined by container so the toolinstaller get well setup
fixed by running `env` with docker-exec to update current PATH and other environment variables
Docker Custom Build Environment philosophy is you should have such tools installed and set by your Dockerfile, not rely on jenkins auto-installers. Anyway need to be fixed as this is a common issue.