2024-08-06 Meeting notes
Date
Attendees
Goals
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
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
| |||
Security Issues
| |||
Unit Tests and Integration Tests.
| |||
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 "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) ?
"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. |