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:  *
https://youtu.be/JocHmIZ9c_U
SonarCloud, but should be insightful.
https://youtu.be/zDkcffDsi24

Hope this is useful,
Paul

On Mon, Aug 25, 2025 at 7:55 PM James Dailey <jdai...@apache.org> wrote:

> 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?
>
>
>
> On Tue, Jul 15, 2025 at 8:57 AM Ádám Sághy <adamsa...@gmail.com> wrote:
>
>> 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.
>> >
>>
>>

-- 
--
Paul

Reply via email to