2024-11-12 Static Code Analysis Meeting notes
- Ingolf Kuss
Date
Attendees
Goals
- Define Static Code Tools for the Go Language
- Resolve the Disagreement within the group
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| Meeting Notes | 11/11 The TC accepted the Go language for official community support. https://github.com/folio-org/.github/blob/master/.github/workflows/go-lint.yml : A Go Linter that runs five static analysis tools with different focuses in Github Actions. | ||
| Subgroup Goal #1 | - 1. Review the current sonar cloud settings Rules für Java There is a Default Sonar Way and a Folio Java Way https://sonarcloud.io/organizations/folio-org/quality_profiles/show?name=FOLIO+Java+Way+2&language=java The Default Sonar Way contains 700 Rules.(157 of those are currently inactive by default). Only 20 of those Rules have been modified by FOLIO Administrators. The Changes are minor, e.g.
These changes have been made by development teams in order to get a test result which is more appropriate to the type of project. "Hurdles" have been gotten rid of. These changes are not overall applicable to each project (a module or a set of modules), but each development teams has their own set of rule modiications. Meeting Notes Ethan: if reactive programming comes up, the guidelines will have to change it's down to that module what guidlines are acceptabel. Descisions need to be made by the development team. A pitch and agreement or a challenge of saying "we don't think it's stringent enough" no immediate failure / Ingolf: TC can accept the module even if there are failures (this has happended several times in the past) - Setting up a new language requires setting up a set of sonar rules or whatever rules. Always start from the default set of rules. Ethan: Java looks different now than 20 years ago. Not allowing changes is not a good strategy. Julian: 20 Rules are different in the Folio Java Way and the Default Sonar (Java) Way Ingolf: The TC reviews the changes to the rules / There should be a TC admin for each code scanner, If a new language or a new code scanner comes out: We first start from "Default" Settings We need to protect (the code basis) from bad actors (I know that you are not bad actors). Ethan: I would accept that. Although it causes a blocker, it induces more administrative overhead and friction. Not any failure is inaccaptable. Ingolf: A different module could have 20 different differences from the Default Way than another module. The TC needs to know what has been changed and approve the changes. Ethan: Other code scanners maybe work differently than Sonar Cloud does. Ethan: If the biggest problem is to set up the static code analysis, that's a good thing. There are many more challenges that the dev teams have to face in the case of setting up a new language. The group disagrees on the following question:
Ethan says no, Julian says yes. Ingolf: Since we allow that the group is free to set up a new code scanner in the Static Code Analysis Guidelines (see Goal #2) (the proposal thereof) without explicit TC approval, it will be contradictory to force them at the same time to use SonarCloud in any Java project. Ethan: Modules could have multiple languages. Ethan: Example : a micronautic language; it might be java based, but SonarCloud may be not the best scanner. The Group wants the TC to vote on this:
Proposal: We recommend SpringWay and Vertex to use SonarCloud. If something new comes out , the module should be free to use it. It mustl be made explicit and reviewed by the TC. Julian disagrees. | ||
| Subgroup Goal #2. | - 2. Propose a generic set of guidlines for static code analysis that is platform agnostic The group proposes the following set of guidelines:
Explanations: The team must describe the location of the code analysis if not Sonar. | ||
| Subgroup Goal #3 | - 3. Propose edits to our current documentation concerning static code analysis to make it less sonar cloud centric
|