...
| Time | Item | Who | Notes |
|---|---|---|---|
TC agreed to split off the test coverage and testing topic into a separate subgroup. Goals of the Subgroup: - 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). Rules für JavaOnly 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 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. Ethan: describe the location of the code analysis if not Sonar 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 . A challenge of saying "we don't think it's stringent enought" no immediate failure - settings up a new language requires setting up a set of sonar rules or whatever rules - Java looks different now than 20 years ago. Not allowing changes is not a good strategy. - 20 Regeln sind unterschiedlich nur kleine Änderungen; wahrscheinlich haben sie zu viele Warnungen bekommen es repräsentiert Hürden / wir aus dem Weg geschafft whether a pitch or a challenge Ingolf: TC reviews the changes to the rules / there is a TC admin for each code scanner If a new language or a new code scanner, we first start from "Default" setting Protect from bad actors Ethan: I would accept that. Although it causes a blocker, more administrative overhead, friction Not any failure is inaccaptable Ein anderes Modul könnte 20 andere Unterscheide haben Andere Code Scanner arbeiten vielleicht anders als SonarCloud - Default-Rules for each code scanner per language are the standard - the Team is free to change the rules according to their development needs, they are admins to the code scanner repository (e.g. https://sonarcloud.io/organizations/folio-org/) - the changes need to be made explicit to the Reviewer and reasonably justified - the Reviewer is someone from the TC who does the code review -- if the biggest problem is to set up the static code analysis, that's a good thing example : a micronautic language; it might be java based, but SonarCloud is not the best scanner Muss man SonarCloud verwenden, wenn es ein Java-Projekt ist ? - modules could have multiple language Wenn es ein SpringWay oder Vertex-Modul ist, muss man SonarCloud verwenden: TC to vote on this ? we recommend springWay and vertex to use SonarCloud. If something new comes out , the module should be free to use it. It will be made explicit and reviewed by the TC. Julian disagrees. | |||
| - 2. eine generische Menge von Richtlinien beschreiben für statische Code-Analyse ( Propose a generic set of guidlines for static code analysis that is platform agnostic) | |||
| - 3. Make the documentation less sonar cloud specific (Propose edits to our current documentation concerning static code analysis to make it less sonar cloud centric )
| |||
- Default rules for each code scanner per language are the standard.
|
...