Re: [xwiki-devs] [Proposal] Get rid of sonar.xwiki.org?

Hi devs, I’ve now progressed on this over the weekend. * I’ve configured ci.xwiki.org to define a ’sonar’ config that points to sonarcloud.io * I’ve modified our top level pom in commons to use the proper sonarqube plugin (we were using a too old version for sonarcloud) * I’ve modified and integrated our main jenkins pipeline to add a parameter “sonar=true|false” to deploy to the ’sonar’ config. * I’ve modified the Jenkinsfile of commons, rendering & platform so that the ‘quality’ build deploys the results to sonarcloud.io. This is the best part since it’s now integrated in our pipeline and we don’t need the 4 specific jenkins jobs for sonar that we have. FTM I’ve disabled them, but my plan is to remove them completely next week after I verify that it all works fine. * Bonus: we now have SonarQube results displayed on the jenkins page. For ex, see https://ci.xwiki.org/view/Recommended%20Builds/job/XWiki/job/xwiki-commons/… Build speed consequences: * I think this makes use loose 3mn on the commons build, see https://ci.xwiki.org/view/Recommended%20Builds/job/XWiki/job/xwiki-commons/…. Build #512 is the one that ran sonar:sonar and deployed to sonarcloud.io. * I’m waiting for the rendering and platform builds to see how much time more it takes there. Next steps: * Tune the rules on sonarcloud.io and define a strategy to use it * Later on, decide if we want to break the CI job on some rules (quality gate) * Tune the sonarqube config in our poms so that we get correct jacoco coverage (right now it doesn’t seem correct and probably doesn’t include integration testing). I’m working on this one ATM. * Continue investigating the usage of https://github.com/jenkinsci/parameterized-scheduler-plugin to be able to have scheduled triggers inside our main pipeline to run some parts of the build only at certain times (like being able to run the sonar part only once every day for ex if that’s what we want). We could also imagine running it only once out of 3 builds for example (easier to do I think). Thanks -Vincent