Metrics View in CodeChecker

Aperta
  • Qualcosa non va?
#4,638 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 8 giorni

@adilzhetigenov ci sta già lavorando.

Dal 1/10/2026.

  • #5120 di @adilzhetigenov — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python, sql
Ambito
backend, databases, frontend

Direzione di ricerca

The payload names no source files. It sketches a Metrics table and a Metrics_Type table, YAML client metrics uploaded during the store procedure, server metrics written at the end of that procedure, and a directory-level navigation view. Open questions about which files to measure remain unanswered, and open pull request #5120 already targets this work. Read that PR and the three comments before proposing anything; done would mean the maintainers have settled the schema and the open questions.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

discussion :bulb: new feature :+1:

CodeChecker will have a metrics view, where different scalar metrics can be stored per run and run history event (storage event) for each file and directory.

Metrics stored per run per run history event
In this view a single run and storage event must be selected. the default is the latest storage event. The metrics of of the selected storage version is shown for each file and directory stored in that run. The metrics should be stored for each run history event.

Initially the feature should support at least the following metrics:

  • Lines of Code
  • Effective Lines of Code
  • Number of outstanding reports per severity level (At the time of storing the results, as the report count may change with setting some of the reports resolved. In such case a new storage must be performed.)
  • Report density Number of outstanding reports / effective lines of code

Optionally the following metrics may be stored

  • Cyclomatic complexity (per file)
  • Number of duplicated lines of code
  • Number of unresolved SEI cert violations

Navigation
A directory level navigation should be provided where the metrics are displayed for each file and direcory. When the user clicks a file, the source code view is shown for that specific file and version. When the user clicks a directory, the navigation enters into that folder.

Calculation of Metrics
There can be 2 types of metrics:
a) client calculated metrics (such as test coverage)
b) server calculated metrics (such as number of outstanding reports)

The metrics are only calculated at the store event and are read only (cannot change after store). New metrics value can be stored with a new store.

Aggregation

The metrics should be stored per file, but should possible to be aggregated on the directory level.

The directory level aggregation summary must be supported.

Visualization & Gating (Future work)
The implementation must allow the visualization of trend lines (by time) for each metric and allow the future implementation of gating on the last change of the metric, or the current status of metric.

Open questions

  1. For which files we need to calculate the LOC metrics ? - All text files?
  2. The content of which files need to be stored? - All text files / only the files where we have reports?
  3. Which versions of the source code files need to be stored? - Only the latest version in the run?

Implementation

Client calculated metrics should be uploaded to the server in YAML files along in the store procedure. Exact YAML format to be defined.
Server calculated metrics should be stored at end of the store procedure.

Database Schema
Metrics Tabe:

Metrics ID | File ID | Run History ID | Metrics Value | Metrics Type

Metrics_Type Table

Metrics Type ID | Metrics Name | Metrics measure

Lingua principale
Python
Stelle
2.6k
Fork
494
Merge medio
9g 2h
PR unite (30g)
23

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ericsson/codechecker

Tutte le issue di Ericsson/codechecker

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.