Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#4,133 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

@anth-volk já está trabalhando nisso.

Desde 29/10/2026.

  • #4134 de @anth-volk — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
github-actions, python
Domínio
ci-cd, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
18
Forks
33
Merge médio
2d 7h
PRs com merge (30d)
64

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de PolicyEngine/policyengine-api

Todas as issues de PolicyEngine/policyengine-api

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.