Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#4,133 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

@anth-volk 已经在做这个了。

开始于 2026年10月29日。

  • #4134 来自 @anth-volk —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
停滞
技术栈
github-actions, python
领域
ci-cd, testing

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Python
星标
18
派生
33
平均合并
2 天 7 小时
30 天内合并 PR
64

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

PolicyEngine/policyengine-api 的其他 Issue

查看 PolicyEngine/policyengine-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。