2024-11-12 Static Code Analysis Meeting notes

Owned by Ingolf Kuss
Nov 11, 2024
3 min read

Date

Attendees

Goals

  • Define Static Code Tools for the Go Language
  • Resolve the Disagreement within the group

Discussion items

TimeItemWhoNotes

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
           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.
  • Change in the Level of Criticality if Rule fails
  • Change in a threshold level

             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:
  • Does one have to use SonarCloud if one is having a Java project ?
      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:
  • If it is a SpringWay or Vertex based module, does the dev team have to use SonarCloud fpr static code analysis ?
                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:

  • Default rules for each code scanner per language are the standard.
  • The team is free to change the rules according to their development needs.
  • The team is free to set up a new code scanner without explicit TC approval
  • The changes need to be made explicit to the reviewer and reasonably justified.
  • The reviewer is a member of the TC who does the code review

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

Action items

  •