Hi everyone,
I’ve already requested and received admin rights for SonarCloud.
This week, Adam Monsen and I will review the current settings and put together a plan, which we’ll share with the community.
In the meantime, I’ve disabled the Sonar GitHub Action until we have it properly configured.
Best regards,
Adam Sent from my iPhone On 26 Aug 2025, at 05:46, Aman Mittal <aman.mittal3052...@gmail.com> wrote:
I just take arround the coverage report. At the sonar cloud, here are some key takeaways.
Coverage is set as per default sonar conditions.
Community needs to decide what should be the acceptable parameters.
Eg. Cognitive complexity,
Number of parameters, and so on.
Relying on default settings may not be good idea. As more issues are being generated due to these issues.
Deprecated methods are still being used from java 8.
A developer can see these issues from the sonar lint themselves.
But concerning is that rule is not enforced properly and issues are still increasing. That's why coverage is giving 0.0.
If these points can be addressed then sonar can be implemented, but rule set must be discussed with the community first. What rules must be relaxed or added.
Paul et al. - That is the question I am asking. If no one is willing to step up and work with Apache infra and our specific config, then this should be pruned. It currently has no value and suggests something unhelpful.
BUT, It is freely offered by SonarCloud to the Apache Software Foundation (ASF), so it is of potential value if we have someone managing it. The account is managed by the ASF Infra team.
The current command used is Run as: gradle clean bootRun
IF you look at that gradle task in our github, I would guess/suppose that it is insufficient for the SonarQube needs. There is a need to look at the gradle tasks but also the current SonarQube config. e.g. source files for the test coverage may be located in a setting, specific to Fineract config. or e.g. set the evaluation look back to 90 days or ?
If someone wants to look at this and figure out what's not working, specifically and for Fineract, please do so. See the rest of this thread, prior postings, for more information.
Thanks,
An unconfigured SonarQube has no value. The current situation, where it's not running on PRs (pull requests) and shows zero coverage, means we're not getting any of the insights it's designed to provide. (non-tech explanation)
Action Steps: - Yes / No to use SonarQube.
- IF NO, remove SonarQube, it produces no value as is and STOP HERE.
- IF YES, use the following list as an activation process, so that SonarQube is active and produces accurate reports.
- Generate SonarQube Token:
To generate a SonarQube token, create a security token within your SonarQube server instance. This is a one-time process, and the token will be used to authenticate your CI/CD pipeline with the SonarQube service.
- Add Token in Repository Secrets: Store the generated token as a secret in your project's GitHub repository. This protects the token from being exposed in public code.
- Create a GitHub Actions Workflow: Write a
.yml file in your repository's .github/workflows directory. This file will define the automated job that runs SonarQube analysis on every pull request. - Configure Build Tool: Ensure your project's build tool (e.g., Maven, Gradle) is correctly configured to generate the necessary reports, such as code coverage reports from the required tool. SonarQube uses these reports to gather its metrics.
- Define the pass/fail criteria to block the introduction of new issues on New code. The essential metrics to include are:
- Bugs: Fail the gate if any new bugs are found.
- Vulnerabilities: Fail if any new security vulnerabilities are detected.
- Code Coverage: Set a mandatory minimum percentage of unit test coverage on new code.
- Maintain: Block new code smells above a defined threshold.
How to videos: SonarCloud, but should be insightful.
Hope this is useful, Paul
Bringing this up again - This is always failing. Can we find a way to configure that so the quality gate config includes the test coverage we do have?
Hi Adam
Well, there are many moving parts here:
1. Sonarqube report can easily be misleading:
It got executed only on the `develop`
- 0% coverage shows the last 30 days I believe, so in the last 30 days there was 0 unit test written.
- In my understanding - but i might be wrong - sonarqube marks it as failed, if the metrics (coverage, bugs, duplication, etc.) got worse than before…
2. Since it got not executed on PRs automatically, we always know the outcome only after the merge whether it got better or worse…
We can consider changing on this and add sonarqube metrics as one of the acceptance criteria of a PR.
I dont know whether someone is reviewing actively, probably we should… at least before new release maybe?
I hope it helps!
Regards,
Adam
> On 2025. Jul 15., at 17:41, Adam Monsen <meonk...@apache.org> wrote:
>
> It looks like the sonarqube quality gate always fails.
>
> Something seems broken with the coverage metric. If you click "Show Older Activity" at https://sonarcloud.io/project/overview?id=apache_fineract every commit says "0.0% Coverage".
>
> I only see the main branch and no PRs at https://sonarcloud.io/project/overview?id=apache_fineract .
>
> More broadly: I'm wondering if the sonarqube tool/integration is useful and/or actually being used with/for Fineract.
>
--
|
