Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Implement a change-aware StrykerJS workflow for pull requests

Aperta
  • Qualcosa non va?
#8,906 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
ci-cd, frontend, testing-qa

Direzione di ricerca

Start with parent epic #8810 and the StrykerJS incremental-mode documentation, then inspect the existing frontend mutation-testing workflow and configuration. Use the parent benchmark to select the incremental strategy, define when broader safety runs are needed, and document incremental-state provenance and invalidation. Done means the observational PR workflow reports its mode, results, failures, and inspectable mutation output without unnecessary full-suite runs.

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

Descrizione

frontend javascript

Goal

Run frontend mutation testing on pull requests before merge without executing the complete LibreSign frontend mutation suite for every normal change.

Use the strategy selected by the incremental benchmark under the parent epic.

Execution model

The workflow must distinguish changes for which native StrykerJS incremental analysis is trustworthy from changes that require a broader forced run.

Normal source and test changes

Use the validated incremental strategy.

With the Vitest runner, StrykerJS can report test files and exact test locations, so test-only changes should be handled by the native incremental analysis when the benchmark confirms the expected behavior.

Mutation/test infrastructure changes

Changes that StrykerJS incremental mode cannot safely detect must trigger the agreed broader safety mode.

Examples to evaluate include:

  • Stryker configuration;
  • Vitest configuration or shared setup;
  • relevant npm dependency changes;
  • environment inputs used by the tests;
  • snapshots when applicable;
  • other support files that affect test behavior but are neither mutated source nor reported test files.
No relevant mutation changes

The workflow must complete successfully without expensive mutation work.

This is required so the eventual required status check is always produced.

Incremental state

Use a trustworthy previous Stryker incremental result.

Do not reuse an incremental report when its provenance or compatibility with the current baseline cannot be established.

The implementation must document how the baseline/incremental result is produced, stored, selected and invalidated.

Failure behavior

The workflow must not produce a false-green result when:

  • Stryker cannot start;
  • Vitest cannot run;
  • configuration is invalid;
  • the mutation process crashes;
  • required incremental state is invalid or cannot be trusted;
  • a change falls outside the assumptions of incremental analysis and the broader safety mode cannot run.

Do not hide failures behind continue-on-error or unconditional success handling.

Reporting

Provide useful PR diagnostics and preserve available machine-readable/HTML reports when practical.

The job log should make clear:

  • which execution mode was selected;
  • how many results were reused;
  • how many mutants were rerun;
  • runtime;
  • mutation summary.

Rollout

Initially run this workflow observationally while its performance and signal are verified on real pull requests.

Making the check required belongs to the later enforcement issue.

Done when

  • Normal source/test changes use the validated incremental mutation strategy.
  • Changes outside incremental detection use the agreed broader safety mode.
  • PRs without relevant changes still produce a successful check.
  • Incremental state has documented provenance and invalidation rules.
  • Operational failures are visible and cannot silently pass.
  • The workflow produces inspectable mutation results.
  • Normal PRs do not execute the complete frontend mutation suite unnecessarily.
  • Runtime stays within the range justified by the benchmark.

References

Lingua principale
PHP
Stelle
835
Fork
167
Merge medio
21h 30m
PR unite (30g)
375

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 LibreSign/libresign

Tutte le issue di LibreSign/libresign

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.