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

Split the release tests over six runners, and stop repeating the merge run's checks on the release commit

Aperta
  • Qualcosa non va?
#4,133 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@anth-volk ci sta già lavorando.

Dal 29/10/2026.

  • #4134 di @anth-volk — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
github-actions, python
Ambito
ci-cd, testing

Direzione di ricerca

Start with the release workflow and the existing release tests, then inspect the checks and merge-run status referenced by issues #4124 and #4129. Map how the release commit is created and how make test collects tests so the six shards can be deterministic and a completeness check can detect missing or repeated tests. Done means eligible release commits skip the repeated checks only when the merge checks passed, all tests run exactly once across six runners, and failures block the release.

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

Descrizione

Problem

Once the release tests run in their own job (#4124) and beside the database jobs (#4129), a Public API release run is still about 18 minutes from its start to the staging Cloud Run deploy, for two reasons that only help together:

  • The release run repeats the merge run's checks. It runs lint, the quality guards, both Alembic checks and the cross-database integration tests again, about 10 minutes before publish-git-tag and the staging database jobs can start. The merge run passed them on a tree that differs only in release files: versioning changes the version in pyproject.toml, refreshes uv.lock, rebuilds CHANGELOG.md and removes the fragments it built. Nothing checks that the release commit changes nothing else, so today the repeat is the only protection against, for example, a uv lock that re-resolved dependencies.
  • The release test suite runs in one process. make test (about 3,900 tests) takes 14 to 18 minutes on one runner, so skipping the checks alone would leave the tests as the longer branch.

Expected behaviour

  • A new job checks the release commit before the checks start. The release run skips lint, the quality guards, both Alembic checks and the integration tests only when:
    • the release commit changes nothing but release files: the [project] version in pyproject.toml, the project's own version entry in uv.lock, CHANGELOG.md, and fragments it removes from changelog.d/; and
    • the merge commit's Push run passed all five checks.
  • If either fails, the checks run as today, and publish-git-tag requires the same ones to pass as today.
  • The release tests run on six runners, split deterministically so that every test runs exactly once, and a check fails the release when any collected test did not run in exactly one shard.
  • No new dependency.

Expected saving: about 10 to 12 minutes per release beyond #4124 and #4129 (estimate), with the staging deploy starting about 7 minutes into the release run instead of about 19.

Lingua principale
Python
Stelle
18
Fork
33
Merge medio
2g 7h
PR unite (30g)
64

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 PolicyEngine/policyengine-api

Tutte le issue di PolicyEngine/policyengine-api

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.