2024-08-06 Meeting notes

Owned by Ingolf Kuss
Last updated: Aug 06, 2024 by Julian Ladisch

Date

Attendees

Goals


Discussion items

TimeItemWhoNotes



Module Acceptance Criteria v2.0: https://github.com/folio-org/tech-council/blob/c7fd65c7c537eff0e2f9c50d6c46bc6cc7701359/MODULE_ACCEPTANCE_CRITERIA.MD

Example for code Dupliction Detection (an example from  MegaLinter based on jscpd analysing Grails based mod-serials-management (dashboard)) :

┌────────────┬────────────────┬─────────────┬──────────────┬──────────────┬──────────────────┬───────────────────┐
│ Format     │ Files analyzed │ Total lines │ Total tokens │ Clones found │ Duplicated lines │ Duplicated tokens │
├────────────┼────────────────┼─────────────┼──────────────┼──────────────┼──────────────────┼───────────────────┤
│ groovy     │ 96             │ 4890        │ 32306        │ 23           │ 202 (4.13%)      │ 2633 (8.15%)      │
├────────────┼────────────────┼─────────────┼──────────────┼──────────────┼──────────────────┼───────────────────┤
│ properties │ 20             │ 893         │ 3301         │ 0            │ 0 (0%)           │ 0 (0%)            │
├────────────┼────────────────┼─────────────┼──────────────┼──────────────┼──────────────────┼───────────────────┤
│ sql        │ 1              │ 26          │ 261          │ 0            │ 0 (0%)           │ 0 (0%)            │
├────────────┼────────────────┼─────────────┼──────────────┼──────────────┼──────────────────┼───────────────────┤
│ bash       │ 8              │ 231         │ 1343         │ 2            │ 64 (27.71%)      │ 359 (26.73%)      │
├────────────┼────────────────┼─────────────┼──────────────┼──────────────┼──────────────────┼───────────────────┤
│ Total:     │ 125            │ 6040        │ 37211        │ 25           │ 266 (4.4%)       │ 2992 (8.04%)      │
└────────────┴────────────────┴─────────────┴──────────────┴──────────────┴──────────────────┴───────────────────┘
Configuration used to exclude domain classes that cannot be written without duplication:
COPYPASTE_JSCPD_ARGUMENTS: '--ignore-pattern "import .*| *@Defaults.*"'

Sonar example page for raml-module-builder https://sonarcloud.io/summary/overall?id=org.folio%3Araml-module-builder :

Exclude automatically generated code from duplication detection.




Major Code Smells

  • It does not have to be Code Narc
  • The metric used for module acceptance is the the highest severity level
    • Sonarqube uses the severity levels High - Medium - Low.
    • CodeNarc uses the severity levels Critical - Medium - Minor.



Security Issues

  • CHG: "sonarqube hasn't identified any security issues"  => sonarqube or any equivalent security scanner, if Sonarcube does not support the development framework.



Unit Tests and Integration Tests.

  • Integrations: If the new module works together with existing modules, the team must provide a result of an integration test.
  • Integration test must be in a specific repository in FOLIO:
  • 80% Backend Unit Test: Is this number always applicable ?
  • Frontend: Front-end unit tests written in Jest/RTL at 80% coverage (O.K.)

ToDos

"SonarCube is not configured in a way that we want it to be."  → Can we please specify what is meant by this ?

Static Code Analysis is not always possible.  → Ingolf and Julian disagree.

"The possibility to obatin some kind of standard output. This will generally lead to a YAML document or something." → A YAML document is not necessary to provide. TC just needs to know "80%" (for example) or "Criterium fulfilled: yes or no".




" What about the module descriptor ?" → This is not code. Does not need to be tested.

"Question about CRUD API Tests" → We think those also need to be tested. If the API implementation is trivial, then the test will also be trivial (smile)

"The (development) teams will need to determine the kind of testing method." (not the TC) - What does "testing methode" exactly mean ? The Testing Tool or the scope of the test (i.e. integration test or unit test) ?

  • Shall we make a proposal how to evaluate Grails projects ? (Julian, Ingolf: No. It is a taks of the development team.)

"Also, it needs to be reproducible for the Community." → The development teams must use fully automated (not manual) procedures for the calculation of the metrics (=characterictis numbers)  and must document their tools (it maybe a link to github Actions, Sonar via Jenkins or other). Thus, the metrics need to be automatically created on each Pull Request.



Next Time
Make a concrete proposal to the TC to change the Acceptance Criteria.

Action items

  •