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 <jdai...@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 <pchristi...@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 <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 >> > -- -- Paul
