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

Required checks lint, build and test are satisfied by a skip when dependency-locks fails

Đã đóng Phù hợp với người mới
  • Có gì không ổn?
#3,755 2 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 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, python, yaml
Lĩnh vực
ci-cd

Hướng nghiên cứu

Xem xét .github/workflows/ci.yml và các ruleset của repository để xác nhận job dependency-locks và các check phụ thuộc vào nó. Thêm tính cập nhật của dependency lock vào các check bắt buộc, sau đó xác minh rằng lỗi dependency-locks sẽ chặn merge queue mà không coi các check phụ thuộc là thành công. Xác nhận liệu có quy tắc bảo vệ branch hiện có nào cung cấp cơ chế thực thi bổ sung hay không.

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

Mô tả

The required checks lint, build, test (HTTPX2), test (Python 3.10) and test (Python 3.14) all come from jobs that declare needs: dependency-locks, and dependency-locks is not itself a required check. Because GitHub treats a skipped required check as satisfied, a failure in dependency-locks skips all five and the branch rule is met with none of them having run.

From About protected branches:

Required status checks must have a successful, skipped, or neutral status before collaborators can make changes to a protected branch.

The state in .github/workflows/ci.yml on main today:

job check name required needs
dependency-locks dependency lock freshness no —
lint lint yes dependency-locks
build build yes dependency-locks
test test (Python 3.10 / 3.14) yes dependency-locks
test-httpx2 test (HTTPX2) yes dependency-locks

None of the five carries an always() or !cancelled() guard, so the default skip-on-upstream-failure behaviour applies. dependency-locks failing is not hypothetical — it is the job that fails when pyproject.toml and uv.lock disagree, which is exactly the situation where you would most want lint and the test suite to run.

The narrowest fix is to make the dependency it gates on a gate itself, by adding dependency lock freshness to the required checks in the ruleset. Nothing in the workflow changes, and a lock failure then blocks on its own terms rather than by silently withdrawing four other checks.

The alternative, if you would rather not grow the required list, is the aggregate-gate shape you already have elsewhere in the ecosystem: one job with if: always() that inspects needs.*.result and exits non-zero, required in place of the individual checks.

Two caveats on scope. Those five jobs also carry if: github.event_name == 'push' || github.event_name == 'merge_group' || github.event.pull_request.head.repo.fork, so on a same-repo pull request they are skipped by design and the real run happens in the merge queue; the exposure I am describing is inside the queue, where a dependency-locks failure would skip the rest of the run and the queue would see satisfied checks. And I can only read your rulesets, not classic branch protection, so if additional enforcement exists that I cannot see, this may already be covered.

Found with greenwash, a tool I wrote for auditing this specific failure mode; greenwash audit --repo openai/openai-python reproduces it.

Ngôn ngữ chính
Python
Star
31.7k
Fork
5.8k
Merge trung bình
2 ngày 6 giờ
Pull request đã merge (30 ngày)
104

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 openai/openai-python

Tất cả issue của openai/openai-python

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.