Feature : generation docker-compose by maven (manual from @dedece35)

[dedece35]

initial PR (before migration): https://github.com/cnumr/ecoCode/pull/89 (plop @Silicoman )

[Silicoman]

Hi @dedece35,

I have checked #8 and latest messages. Can you detail what you finally want? Except the use of maven image with multistage Dockerfile, that can be discussed. I don't know what you are wishing.

Thanks for your review :)

[dedece35]

Hi @Silicoman and @obeone

to summarize our discussions and what I understand between your two PRs. I like following ideas :

• ... of @Silicoman to dynamise SonarQube version and langages modules versions from pom.xml files
• ... of @obeone to have an already built image to allow a quick start running environment

But, there are several problems before merging them :

• migration of code to new github repositories and technical refactoring (to follow several good practices) have big bad consequences to your PRs : they are really out-of-date :( ... for example, first, ecocode repository has been splitted in ecocode repository and ecocode-mobile repository; secondly, there is no src/src directory yet (to follow maven good practice), etc ...
• there is another important PR #15 in progress to upgrade our technical stack (9.3 to 9.8 SonarQube version, dependencies versions, ...) made by @oussamaLaribi and reviewed several times by me. We are about to merge this PR and it will make another big bad consequences to your 2 PRs
• your two PRs deal with the same subject (improve our docker usage), thus we can't merge these 2 PRs in the same time and we have to prioritize them : I think the one simpliest has to be merge first, I mean #9 for me.

In conclusion, I think we have to :

• first, merge the PR #15
• secondaly, upgrade the PR #9 from main branch (to make the work on java plugin for example instead of android plugin because migrated to another repository)
• thirdly, merge PR #9
• fourthlyn upgrade the PR #8 from main branch
• finally, merge PR #8

Whta do you think about it @Silicoman and @obeone ?

[Silicoman]

Thanks to sharing your pov.

Due to technical change, i think the simpliest way to solve #9 is to recreate a branch with the little change (adding a plugin and template docker-compose). I will precise tickets/branch to close due to duplication.

[obeone]

Hi,

I agree with this procedure. I see #15 is merged so I'll try to update #8 quickly

[dedece35]

Hi @Silicoman and @obeone, I agree with you.

[dedece35]

Hi @obeone,

#15 is merged. you can merge now. thank you.

[dedece35]

HI @Silicoman, can you resolve conflicts in this PR before progress this idea ?

[MP-Aubay]

Hi @dedece35 @Silicoman @obeone ,

I was just thinking, with the new release system (thx @dedece35) maybe it is possible to provide a better quick start that does not need to build jar.

For example if we had a Dockerfile like this one :

FROM sonarqube:9.8-community

RUN wget -O /opt/sonarqube/extensions/plugins/ecocode-java-plugin.jar https://github.com/green-code-initiative/ecoCode/releases/download/0.2.1/ecocode-java-plugin-0.2.1.jar
RUN wget -O /opt/sonarqube/extensions/plugins/ecocode-php-plugin.jar https://github.com/green-code-initiative/ecoCode/releases/download/0.2.1/ecocode-php-plugin-0.2.1.jar
RUN wget -O /opt/sonarqube/extensions/plugins/ecocode-python-plugin.jar https://github.com/green-code-initiative/ecoCode/releases/download/0.2.1/ecocode-python-plugin-0.2.1.jar
RUN wget -O /opt/sonarqube/extensions/plugins/ecocode-android.jar https://github.com/green-code-initiative/ecoCode-mobile/releases/download/0.1.0/ecocode-android-0.1.0.jar

And some minor change to the existing docker-compose it could be simple enough for everyone (just need docker and docker-compose).

What do you think about it ?

I'm still wondering about two things :

• How to handle automaticaly updated versions ?
• Do we put this solution in each ecoCode repository or do we provide an unique Dockerfile in another repository ?

Regards, Mikaël

[obeone]

Hi, sorry, I was quite busy these days.

Yes @MP-Aubay, I think it’s a good idea. If now we have jar files published in release section, it’s possible to include it in Dockerfile directly.

To build it, it’s possible to use Github Action to do that, it can be run on new release. I’m not sure it can be run on other repository release, but I think a good practice is to do scheduled build (everyday for example, to include security update), and there are actions to get other repository latest’s release (for example : https://github.com/marketplace/actions/get-latest-release).

To sum up :

• On same repo, it can be built directly on new release event
• On different repo, it can be built regularly

(Maybe it’s possible to handle incoming webhook, but I didn’t look for, for now)

[dedece35]

Hi @obeone, @MP-Aubay, @Silicoman, yes good quick idea. as @obeone said, we can automatically update DockerFile at the end of release process for example. other thing, we can get last versions with an URL like curl https://api.github.com/repos/green-code-initiative/ecoCode/releases/latest | grep "ecocode-" and then upgrade DockerFile.

[dedece35]

Hi @obeone can you resolve conflicts please before I take a look again :p

thx.

[obeone]

Hi !

I just read again the discussion, and I think it's better to use jar's created with as release one (if needed). It would be a non-sense to build locally the plugins, upload it to github, to download it again, and finally embed it in container. The Dockerfile I wrote already build the plugin, and is able to directly upload it as release if you want (for example, if core team create a tag named "vX.X.X", it build and create a draft release).

And for the main subject of this PR, yup, I can work on the docker-compose.yml, but I'll do another PR (because there is too many conflict, and I don't have write access to this repo, so I can't work on this branch)

[github-actions[bot]]

This PR has been automatically marked as stale because it has no activity for 30 days. Please add a comment if you want to keep the issue open. Thank you for your contributions!