Simplify the complete Infection CI workflow and preserve reports
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- github-actions, php
- Ambito
- ci-cd, devops, testing-qa
Direzione di ricerca
Start by reviewing infection.json5, the existing complete Infection workflow, and the normal PHPUnit workflows to compare compatibility coverage and identify the canonical runtime. Check the related pull-request workflow in #8901 and verify safe parallelism, report formats, and available metadata. Done means a manually runnable workflow preserves logs and machine-readable reports, exposes runtime details, and visibly fails on operational errors without an arbitrary score threshold.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Goal
Simplify the complete Infection GitHub Actions workflow so LibreSign has one reliable CI execution path for full mutation runs and preserves enough evidence for baseline analysis.
This workflow is for complete mutation runs. It is separate from the normal pull-request change-aware mutation workflow.
Current problem
The current Infection workflow combines mutation testing with a PHP/Nextcloud compatibility matrix.
Mutation testing and compatibility testing answer different questions.
LibreSign already has normal PHPUnit/CI coverage for supported runtime combinations. Repeating the complete mutation suite across a compatibility matrix can multiply an already expensive workload without evidence that each combination provides distinct mutation-testing signal.
Investigation
Before removing the current matrix, verify:
- what compatibility coverage is already provided by normal PHPUnit workflows;
- whether Infection has produced mutation-specific failures on different supported PHP/Nextcloud combinations;
- which PHP and Nextcloud versions should define the canonical full-mutation environment;
- whether more than one full-run combination has a measured reason to remain.
Do not remove compatibility coverage merely to reduce runtime.
Do not retain duplicate mutation runs merely because the matrix already exists.
Required outcome
Provide a complete-run Infection workflow that:
- can be started from GitHub Actions;
- uses the agreed canonical runtime configuration;
- keeps workflow YAML focused on orchestration;
- exposes the effective Infection command/configuration;
- preserves useful logs and machine-readable reports;
- records runtime and environment metadata;
- fails visibly for operational Infection/PHPUnit failures.
The workflow must not introduce an arbitrary blocking mutation-score threshold.
Reporting
Preserve enough information to diagnose:
- generated mutants;
- killed mutants;
- escaped mutants;
- uncovered mutants;
- timeout mutants;
- execution errors;
- MSI and Covered Code MSI;
- total runtime.
When Infection supports a suitable machine-readable report, preserve it as a GitHub Actions artifact.
Parallelism
Use only a worker/thread configuration shown to be safe for LibreSign test isolation.
Do not force --threads=1 permanently only to hide shared-state races.
Done when
- The complete Infection workflow has a documented runtime/Nextcloud environment.
- Compatibility testing is not duplicated without a measured reason.
- A complete Infection run can be launched from GitHub Actions.
- Useful reports and logs survive the CI run.
- Runtime and environment metadata are visible.
- Operational failures cannot silently pass.
- No arbitrary merge-blocking score is introduced.
- The workflow is suitable for producing the new authoritative baseline.
Related
- Parent epic: #8897
- Current Infection configuration:
infection.json5 - Pull-request mutation workflow: #8901
- Lingua principale
- PHP
- Stelle
- 818
- Fork
- 146
- Merge medio
- 7h 8m
- PR unite (30g)
- 549
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di LibreSign/libresign
-
good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
LibreSign/libresign#8284 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
backend enhancement php
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
backend enhancement php
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
frontend javascript
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
frontend javascript
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di LibreSign/libresign
Issue simili
-
Infrastructure: actions Module: zmscitizenapi Module: zmsentities php Type: Bug unit tests
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
it-at-m/eappointment#3480 ·
I maintainer di solito rispondono entro 1 giorno
-
CI: composer install fails — league/flysystem 1.x blocked by security advisory GHSA-cxf4-7mrp-vvprApertadevops type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
needs approval
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 3 giorni
-
product / avatars product / self-hosted product / storage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
appwrite/appwrite#13985 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno