Adding SonarQube-ecoCode container image

[obeone]

It use a multistage Dockerfile, so a maven container is used to build jar files, and they are just copied in SonarQube image, without building tools.

I updated documentation to add the docker command on main README (to allow quick test), and in INSTALL documentation, I divided it in three parts : quick start (test version), production version (dockerfile, with this image + postgresql) and a development version, with detailed build instructions and docker-compose start (almost all the original instruction).

I pushed a manual build on my package repos but it can be automatised

[dedece35]

hello @obeone ,
it's a good idea .. but before checking your PR, could you correct the previous build check ?
thanks.

[obeone]

Yes, I will :)

I was waiting for some interest before dealing with merging latest commits.

I work on it quickly

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[obeone]

(Sorry for all the mails you received, I didn’t realized you got mail on every push…)

So, repo is up-to-date.
I also added a GitHub workflow to automatically build the container on new PR and push on main branch.

Failed docker build on this repos is normal, I don’t have rights to push on it. On my fork, everything build and push correctly :
https://github.com/obeone/ecoCode/actions/runs/3489395262/jobs/5839449923

[dedece35]

hello @obeone,

it's a good idea to improve docker installation system. But there is another PR with the same kind of idea : see #89
Maybe merge these two ideas into another new PR in order to improve our docker installation system.
(please see PR #89 created by @Silicoman / @MP-Aubay and my comment)

My feedbacks of this PR :

• I don't known github workflow system, I can't tell you if ok for me or not ... @MP-Aubay ? @glalloue ? @jules-delecour-dav ? @jhertout ?
• maybe put sonarQube version on pom.xml file as the other PR

[obeone]

Hi @dedece35,

I answered on PR #89.

GitHub Workflow is a CI/CD tool (GitHu giving free compute time), so there is no need to have someone who build container, push it etc... It's automatic, and allow an always up-to-date container, built only once for everyone.
(And transparency, because the build process is public)

[dedece35]

@obeone,
thank you for answers ! very interesting !
To have only one place for this discussion, I answer you here, in your PR :p

Thanks for explanations, I know what CI/CD is and concepts : in my society we used Jenkins in a custom CI/CD, but we are migrating to gitlab CI. I just don't known how github workflows works. But thank you.
I agree with to have an ecocode plugin version deployed in github docker repository. Thus, everybody can use an already deployed version without to build it locally.
But in other PR #89, I find interesting that the version of plugin deployed is dynamic and managed from pom.xml. In your solution, I think, the lack is that the version of plugin is always 1.0.0-SNAPSHOT in Dockerfile. Isn't it ? but maybe I miss something ?
(same answer for sonarqube version managment because it is present on Dockerfile and docker-compose.dev.yml)
Actually, the process will always deploy the version 1.0.0-SNAPSHOT and replace the old one, isn't it ?
If yes, (maybe in other PR), we can do modifications to automatically replace "SNAPSHOT" suffix with a new one like date in "YYYYMMDDHHmmss", no ?

In conclusion, your solution is ready to be merged. Thus, I agree to merge this PR, and then make improvements to manage dynamically plugin versions and sonarqube versions.
What do you think about it @MP-Aubay, @glalloue, @jules-delecour-dav, @jhertout, @Silicoman ?

[obeone]

Sorry if my message could have seemed condescending, it was not the idea at all! 😬

Here is my limit : I don't do Java.
I wrote the first version of this Dockerfile just before the ecoCode challenge, because I don't want to install jdk etc on my laptop.
And I improved it after the contest, since I had spent two days on the subject. Since then I have forgotten everything 😅

Clearly we can do better, in particular for the plugins version.

For SonarQube version, plug-ins in June wasn't compatible with latest version. It's better to fix version (at least major number) to avoid an unexpected update.

Since then, I have clearly made progress on Dockerfiles. If a Java developer is motivated to think together a little about doing better, it's with pleasure!

[Silicoman]

Hi everybody,

I'm not sure of the implementation direction.

First question, who is the target of this plugin ?
Users who actually are already using sonarqube and want to improve their instance with a new plugin. Users can use a variety of sonarqube version (v8 LTS (will soon go to v9), v9+, community vs enterprise). They can also build their own image sonarqube with their collection plugins and adding RUN step with "wget github.com/releases/xxx". So you won't distribute docker image but JAR files.

Another risk which isn't analyse, is the question of licence. You are distributing an image from sonarsource with a new licence GPLv3 due to contamination. Previous analyse wasn't check this aspect.

However, +1 about multistage Dockerfile. It's a good idea !

Best regards,

[dedece35]

Hi @obeone, @Silicoman,

First of all, thank you for interesting answers.

@obeone, there is no problem with "condescending" message. I don't understand it like this.
I only want this docker idea to progress.
I understand your purpose to have a docker image to avoid installing tools locally (like jdk) to work with the plugin.
I'm a Java developer since many years. If you want to work together, this will be a pleasure.

But I'm also agree with @Silicoman.
For me the first purpose is to be an official plugin by integration in official SonarQube Plugin repository. Thus, installation would be done by installing Jar files (with official SonarQube Plugin repository) and by a docker image.
For me docker image is only a tool to develop the plugin.

What do you think about it @jules-delecour-dav, @glalloue , @olegoaer, @mdubois81 ?

regards.

David.

[MP-Aubay]

Hi @obeone @dedece35

I agree with @Silicoman, and for me the end goal is to automatically generate a plugin and adding it in Sonarqube Marketplace.

Docker should be use only for development and testing in our case.

Regards,
Mikaël

[obeone]

Hi everyone,

I’m not sure about the target. I think many users can come from elsewhere, but want to begin doing better on there code.

My goal, with this Dockerfile, is because I know want I’m doing when I’m looking for a new tool : some words on search engine, and ctrl+click on various link. I like to be able to quick try (I’m sure it’s not only me), and this is the idea here.

First run, next ones on colleagues computer etc. Install in the company CI/CD process is the very last process, using there owns docker-compose/k8s manifests, but I think we lost a lot of people before

@dedece35 You’re right, JAR alone would be very useful too, and it’s possible to export the JAR files in the same process.

About licences, AFAIK it’s ok, ecoCode is under GPLv3 and SonarQube is LGPLv3, which are compatible

[dedece35]

Hi @obeone ,
we are migrating this repo to a new one : please see green-code-initiative/creedengo-rules-specifications#8
that's why I change this PR to "draft".

[Jberque]

Hi @obeone @dedece35 @MP-Aubay @Silicoman
I just received a message from a "QA Test Manager" wishing to test Ecocode (Java),
He sent me a message through Linkedin, telling me he's struggling to install the plugin.
If an all-in-one-docker-container exists it will be easier to use.
I just wonder how many potential tester just drop the test because it was too hard to install instead of asking for support.