Sonarqube-ecoCode container image

[obeone]

[Replace PR #8]

Added a simple Dockerfile which build a sonarqube container with ecoCode embedded. It allow quick testing ecoCode without needing Java SDK toolchain etc.
I added a workflow too, which build automatically new version on PR, pushes, tags…

I don’t have write access on this repo, so you can test the container built on my repo :

docker run -ti --rm \
       -v sq_ecocode_logs:/opt/sonarqube/logs \
       -v sq_ecocode_data:/opt/sonarqube/data \
       -p 9000:9000 \
       --name sonarqube-ecocode ghcr.io/obeone/sonarqube-ecocode

Ping @dedece35

(PS: I think it can be a big step up to use this image directly in docker-compose.yml, it allow a production ready environment without building)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[dedece35]

why do you want to push a new image on main branch or PR main branch ?
for me on new tag, it's sufficient. Like that, we have a docker image on each release version available.

[obeone]

The idea is to have always a « latest » tag. It’s very useful to be able to test a new feature without waiting a new release (like today, last release was 2 month ago, but a lot of commits was done since).
For PR, it’s almost the same idea : give an easy way to directly test the proposed PR.

All these build will have specifics, logicals, tags. So pushes on main will have « main » and «latest » tags, the PR will have « pr-xxxxxxx », and a release with a semver name (for example 1.2.3) will have « 1 », « 1.2 » and « 1.2.3 » tags. A users can use it to access the version they want, according to their needs

[utarwyn]

Yes it can be interesting to push a "latest" tag with each update of the main branch, it is a fairly common practice of official Docker images. But I am less favorable to upload a public image for each PR, on a source code not yet validated and merged. And I am not sure that we can apply this process for PRs that are made from forks (due to perm issues)

[obeone]

To be honest, I'm not totally confortable with the idea of building unverified code (and not sure it can be possible, because of perms).
But I remain in the idea that not having to build yourself during a review can save time.

Another solution would be with a comment. Someone with write access to the repo can comment with "/build" (for example) and it trigger a build.

[1] https://dev.to/zirkelc/trigger-github-workflow-for-comment-on-pull-request-45l2

[obeone]

Nice for the merge !

There is an error, @dedece35, do you have full rights on green-code-initiative team ?
If not, do someone with can run again the workflow ?
(I never tried package building for team)
https://github.com/green-code-initiative/ecoCode/actions/runs/4450881153

After that, you'll have to go to package page, edit the created package to change permission to public, and link it to the ecoCode repo
https://github.com/orgs/green-code-initiative/packages

[dedece35]

Hi @obeone,

there is an issue about this subject on M1/M2 mac OS: green-code-initiative/creedengo-common#12

maybe the source image not compatible with M1/M2 cpu ?

could you test docker command (in README.md file) with M1/M2 environment ?
thank you.

[obeone]

Hi @dedece35,

I’m working on it, but for now, problem is there is no arm v8 (Apple M) maven:3-openjdk-11-slim (or 17) image, and this is what we use to build jar.

So, there is two ways :

• There is another maven image with support of arm v8
• Begin with build jar on amd64, and after use same jar to create amd64 and armv8 images.

I work on it during next days

[dedece35]

Hi @obeone,
ok thank you.
Could you create an new issue when you will work on it, please ?
(Also, please, affect it to you and make a reference to the current PR #72 )