docker-sonar | offical sonarqube image now and installs | Continuous Deployment library

After further investigations i can say that i made a working docker image for sonar scanner that can work with gitlab ci.

DOCKERFILE

You can simply put a sonar.properties file under /opt/docker-sonar/conf/. This file will be available inside the container under /opt/sonarqune/conf/, because the folder gets mounted as volume.

A full example for a sonar.properties file can be found on github. However all you need to enter is:

Regarding the README.txt issue, you have to create a volume and mount the temp folder (note that I use the postgres setup from anorak:girl). You can then start and stop with no problems.

While this question has some heavily opinionated possible answers, I'll attempt to keep to facts and other things sourced from docker's docs on this

Proper layering of layers in docker has essentially three goals (roughly ordered):

1. correctness: some things need to be combined / ordered for correctness (for example apt operations should always start with apt-get update && ... and apt-get update should never be in a separate RUN layer
2. minimize layers: fewer layers generally means better performance both for build and runtime. This generally means combining layers when possible
3. cache performance: push cacheable layers as high up in the file as possible, note that if a layer is invalidated all layers after that layer are also invalidated

Given that, here's some observations from the things you've proposed:

Given (2) above, you should keep ENV layers combined when possible. Users can override --env at runtime which does not affect build-time layering. Yes if one of the ENV lines were modified in source it would invalidate the rest of the file (3) but generally this is traded off for performance reasons.

generally this is not a good idea, the source on disk is among the most likely things to change, if the source changes, all the layers from the COPY layer downwards are invalidated

This really doesn't matter. EXPOSE is a nearly-trivial layer (it in fact does nothing unless you're linking containers). Since it is cacheable, I'd put it near the top but again, it's trivial to compute and doesn't really change.

tl;dr The maintainer is correct in saying no to all three changes as it will make build and run performance worse.

Just copy your jars to your local folder "sonarqube_extensions/plugins" which should exist next to your docker-compose.yml file and they will be linked into your container according to your referenced docker-compose.yml file.

Old answer

You can modify your existing docker-compose.yml file. Assuming your jar files are located in a folder named "external_jars" next to the compose file and you want these jars to be available inside the container under, for example, /opt/sonarqube/external_jars (I am not familiar with sonarQube and I do not know how the correct structure should look like). Then you can add one line to this excerpt of your compose file: