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

Fermée
  • Quelque chose ne va pas ?
#4,133 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Une pull request liée a déjà été fusionnée.

  • #4134 par @anth-volk — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
github-actions, python
Domaine
ci-cd, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
18
Forks
33
Merge moyen
2 j 15 h
PR mergées (30 j)
110

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PolicyEngine/policyengine-api

Toutes les issues de PolicyEngine/policyengine-api

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.