You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <jd...@apache.org> on 2025/08/26 00:55:10 UTC
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
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 <ad...@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 <me...@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.
> >
>
>
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by Ádám Sághy <ad...@gmail.com>.
Hi Paul,
Thank you for taking the time to share these detailed recommendations. They’re very helpful, and we’ll incorporate them into the upcoming proposal.
Best regards,
Adam
> On 2025. Aug 26., at 15:42, Paul <pc...@gmail.com> wrote:
>
> Thanks James,
>
> Maybe a Starting Place / Plan Rule Set: Below rule sets, IMO should provide a starting point with intentional simplification as its basis. A Cognitive Complexity Setting of "12", is on the lower end of "moderate complexity".
> Benefit: Helps with code simplification today and speeds up future issues which may have dependency on it. Smaller, tighter code, is a also a great way to reduce technical debt.Think of this as a speed limit, that helps keep contributions a little smaller, cleaner and tighter so that more community members can understand the code.
> Tip: A good process should help manage "the thing", but should also help simplify the future. Step by small positive step.
>
> Other suggested rules should apply ONLY to new or changed code en a pull request.
>
> Bugs: Must be 0. Why: Bugs found by static analysis are often critical and should never be introduced into the main branch. Non-negotiable rule.
>
> Vulnerabilities: Must be 0. Why: Similar to bugs, security vulnerabilities should be blocked immediately to protect the project.
>
> Maintainability Rating: Should be 'A'. Why: This metric helps control code smells and ensures new code is easy to read and maintain. (also a tech debt prevention technique)
>
> Code Coverage: Minimum of 70% on new code. Why: This sets a realistic expectation for testing new functionality. This value can be adjusted upward as the community matures testing practices.
>
> Duplicated Lines: Maximum of 3% on new code. Why: Prevents introduction of redundant code and encourages refactoring.
>
>
> Other Rules to Discuss.
>
>
> Deprecated Code Usage: Create a custom rule to flag the use of deprecated methods, such as those from older Java versions. This will highlight areas that need to be refactored over time without blocking new features. Maybe like JAVA.until.date or similar but simple rule, to help identify dead or stagnant code which should not be supported forward ?
>
> BONUS: Who ever steps up and successfully completes the issue, will receive a totally unofficial but humorous, Open Source Seal of Approval logo. SWAG / Bling you may share on your CV, Bio or Social Media account as proof of contribution!
>
> Paul
>
>
> On Mon, Aug 25, 2025 at 9:43 PM James Dailey <jdailey@apache.org <ma...@apache.org>> wrote:
>> 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,
>>
>>
>> On Mon, Aug 25, 2025 at 6:43 PM Paul <pchristison@gmail.com <ma...@gmail.com>> wrote:
>>> 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 <jdailey@apache.org <ma...@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 <adamsaghy@gmail.com <ma...@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 <meonkeys@apache.org <ma...@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
>
>
>
> --
> --
> Paul
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by Paul <pc...@gmail.com>.
Thanks James,
*Maybe a Starting Place / Plan Rule Set*: Below rule sets, IMO should
provide a starting point with intentional simplification as its basis.
A *Cognitive
Complexity* Setting of "12", is on the lower end of "moderate complexity".
*Benefit: *Helps with code simplification today and speeds up future issues
which may have dependency on it. Smaller, tighter code, is a also a great
way to reduce technical debt.Think of this as a speed limit, that helps
keep contributions a little smaller, cleaner and tighter so that more
community members can understand the code.
*Tip*: A good process should help manage "the thing", but should also help
simplify the future. Step by small positive step.
*Other suggested rules should apply ONLY to new or changed code en a pull
request.*
-
*Bugs:* Must be *0*. *Why:* Bugs found by static analysis are often
critical and should never be introduced into the main branch.
Non-negotiable rule.
-
*Vulnerabilities:* Must be *0*. *Why:* Similar to bugs, security
vulnerabilities should be blocked immediately to protect the project.
-
*Maintainability Rating:* Should be 'A'. *Why:* This metric helps
control *code smells* and ensures new code is easy to read and maintain.
(also a tech debt prevention technique)
-
*Code Coverage:* Minimum of *70%* on new code. *Why:* This sets a
realistic expectation for testing new functionality. This value can be
adjusted upward as the community matures testing practices.
-
*Duplicated Lines:* Maximum of *3%* on new code. Why*:* Prevents
introduction of redundant code and encourages refactoring.
Other Rules to Discuss.
-
*Deprecated Code Usage:* Create a custom rule to flag the use of
deprecated methods, such as those from older Java versions. This will
highlight areas that need to be refactored over time without blocking new
features. Maybe like JAVA.until.date or similar but simple rule, to help
identify dead or stagnant code which should not be supported forward ?
*BONUS: * Who ever steps up and successfully completes the issue, will
receive a totally *unofficial but humorous*, Open Source Seal of
Approval logo. SWAG / Bling you may share on your CV, Bio or Social Media
account as proof of contribution!
Paul
On Mon, Aug 25, 2025 at 9:43 PM James Dailey <jd...@apache.org> wrote:
> 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,
>
>
> On Mon, Aug 25, 2025 at 6:43 PM Paul <pc...@gmail.com> wrote:
>
>> 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 <jd...@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 <ad...@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 <me...@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
>>
>
--
--
Paul
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by Ádám Sághy <ad...@gmail.com>.
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 <am...@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.
>
>
>
>
>
> On Tue, 26 Aug, 2025, 8:13 am James Dailey,
> <[jdailey@apache.org](mailto:jdailey@apache.org)> wrote:
>
>
>> 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,
>>
>>
>
>>
>>
>
>>
>> On Mon, Aug 25, 2025 at 6:43 PM Paul
<[pchristison@gmail.com](mailto:pchristison@gmail.com)> wrote:
>
>>
>>> 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
<[jdailey@apache.org](mailto:jdailey@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
<[adamsaghy@gmail.com](mailto:adamsaghy@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
> <[meonkeys@apache.org](mailto:meonkeys@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
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by Aman Mittal <am...@gmail.com>.
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.
On Tue, 26 Aug, 2025, 8:13 am James Dailey, <jd...@apache.org> wrote:
> 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,
>
>
> On Mon, Aug 25, 2025 at 6:43 PM Paul <pc...@gmail.com> wrote:
>
>> 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 <jd...@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 <ad...@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 <me...@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
>>
>
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by James Dailey <jd...@apache.org>.
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,
On Mon, Aug 25, 2025 at 6:43 PM Paul <pc...@gmail.com> wrote:
> 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 <jd...@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 <ad...@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 <me...@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
>
Re: sonarqube quality gate, coverage metric, branches/PRs, overall usage
Posted by Paul <pc...@gmail.com>.
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 <jd...@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 <ad...@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 <me...@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