Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed Beginner friendly
  • Is something wrong?
#3,755 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, python, yaml
Domain
ci-cd

Research direction

Review .github/workflows/ci.yml and the repository rulesets to confirm the dependency-locks job and its dependent checks. Add dependency lock freshness to the required checks, then verify that a dependency-locks failure blocks the merge queue without treating the dependent checks as successful. Confirm whether any existing branch protection rules provide additional enforcement.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
31.7k
Forks
5.8k
Avg merge
2d 7h
Merged PRs (30d)
104

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/openai-python

All issues in openai/openai-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.