Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#4,133 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Một pull request liên quan đã được merge.

  • #4134 của @anth-volk — đã merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
github-actions, python
Lĩnh vực
ci-cd, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
18
Fork
33
Merge trung bình
2 ngày 3 giờ
Pull request đã merge (30 ngày)
72

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của PolicyEngine/policyengine-api

Tất cả issue của PolicyEngine/policyengine-api

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.