Bump djangorestframework-stubs from 3.17.1 to 3.18.0 - #2260
Open
dependabot[bot] wants to merge 1 commit into
Open
Bump djangorestframework-stubs from 3.17.1 to 3.18.0#2260dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [djangorestframework-stubs](https://github.com/typeddjango/djangorestframework-stubs) from 3.17.1 to 3.18.0. - [Release notes](https://github.com/typeddjango/djangorestframework-stubs/releases) - [Commits](typeddjango/djangorestframework-stubs@3.17.1...3.18.0) --- updated-dependencies: - dependency-name: djangorestframework-stubs dependency-version: 3.18.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
ReviewThis is a routine Dependabot bump of Compatibility check: 3.18.0 is noted upstream as "the last version to support Risk assessment:
Looks safe to merge once CI (mypy/lint) is green. |
JSv4
added a commit
that referenced
this pull request
Aug 20, 2026
…ired `main`'s branch protection has no `required_status_checks` object at all, so nothing gates a merge on CI having run, let alone passed. PR #2262 merged with Backend CI never having run on its head commit at all -- and because nothing was required, "no check reported" was not a blocker. The push that merged it then failed at the linter, which skipped `pytest` (0s); `main` sat that way for ~30 hours, repaired only by accident when an unrelated PR's `pre-commit run --all-files` happened to reformat the same file. Requiring *something* is therefore the fix, but requiring the `pytest` job is not, because it leaves a second hole open and opens a third: * GitHub reports a job skipped by its own `if:` as SUCCESS to branch protection. `pytest` is gated on `needs.linter.result == 'success'`, so a red linter skips it and a required `pytest` still reads green. This is not hypothetical: PRs #2260, #2264 and #2265 are all sitting at `linter=failure / pytest=skipped` right now, and would be mergeable under that policy with a red linter. * A workflow skipped by path filtering never reports its checks at all, so the required check hangs Pending forever. With `paths-ignore: docs/**` on the `pull_request` trigger, requiring any job here would make docs-only PRs permanently unmergeable. So the requirable check has to always run and inspect the other jobs itself, telling "skipped because this PR touches no backend code" apart from "skipped because something upstream broke". That is the new `gate` job; its decision table is `.github/scripts/backend_ci_gate.sh`, which carries a `--self-test` that the job runs on every invocation -- a gate whose own logic has silently inverted is worse than no gate. `paths-ignore` is dropped from the `pull_request` trigger for the reason above; the `changes` path filter still keeps the expensive jobs from running, so a docs-only PR now costs two ubuntu-latest jobs of a few seconds. `require_backend_ci_gate.sh` applies the protection change itself, because the obvious `gh api` call is a footgun: `PUT .../branches/main/protection` replaces the ENTIRE object (dropping review rules and the force-push/deletion bans unless they are re-sent), and the narrower `PATCH .../protection/required_status_checks` sub-resource 404s when no such object exists yet. It refuses to require a context name that has never been reported on the branch, since that would block every PR with no error anywhere. Verified by replaying the gate over the last 60 Backend CI runs: it blocks all 8 PR runs with a red linter and both of the merge-commit runs from #2262's window, and allows all 25 genuinely green runs and the 3 with no backend changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JSv4
added a commit
that referenced
this pull request
Aug 20, 2026
…ired `main`'s branch protection has no `required_status_checks` object at all, so nothing gates a merge on CI having run, let alone passed. PR #2262 merged with Backend CI never having run on its head commit at all -- and because nothing was required, "no check reported" was not a blocker. The push that merged it then failed at the linter, which skipped `pytest` (0s); `main` sat that way for ~30 hours, repaired only by accident when an unrelated PR's `pre-commit run --all-files` happened to reformat the same file. Requiring *something* is therefore the fix, but requiring the `pytest` job is not, because it leaves a second hole open and opens a third: * GitHub reports a job skipped by its own `if:` as SUCCESS to branch protection. `pytest` is gated on `needs.linter.result == 'success'`, so a red linter skips it and a required `pytest` still reads green. This is not hypothetical: PRs #2260, #2264 and #2265 are all sitting at `linter=failure / pytest=skipped` right now, and would be mergeable under that policy with a red linter. * A workflow skipped by path filtering never reports its checks at all, so the required check hangs Pending forever. With `paths-ignore: docs/**` on the `pull_request` trigger, requiring any job here would make docs-only PRs permanently unmergeable. So the requirable check has to always run and inspect the other jobs itself, telling "skipped because this PR touches no backend code" apart from "skipped because something upstream broke". That is the new `gate` job; its decision table is `.github/scripts/backend_ci_gate.sh`, which carries a `--self-test` that the job runs on every invocation -- a gate whose own logic has silently inverted is worse than no gate. `paths-ignore` is dropped from the `pull_request` trigger for the reason above; the `changes` path filter still keeps the expensive jobs from running, so a docs-only PR now costs two ubuntu-latest jobs of a few seconds. `require_backend_ci_gate.sh` applies the protection change itself, because the obvious `gh api` call is a footgun: `PUT .../branches/main/protection` replaces the ENTIRE object (dropping review rules and the force-push/deletion bans unless they are re-sent), and the narrower `PATCH .../protection/required_status_checks` sub-resource 404s when no such object exists yet. It refuses to require a context name that has never been reported on the branch, since that would block every PR with no error anywhere. Verified by replaying the gate over the last 60 Backend CI runs: it blocks all 8 PR runs with a red linter and both of the merge-commit runs from #2262's window, and allows all 25 genuinely green runs and the 3 with no backend changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps djangorestframework-stubs from 3.17.1 to 3.18.0.
Release notes
Sourced from djangorestframework-stubs's releases.
Commits
18a30a1Version 3.18.0 release (#1034)31c5403Update stubs for djangorestframework 3.18.0 (#1030)4052203Unlock django-stubs pinning in pyproject.toml (#1033)ebb2bccUpdate astral-sh/setup-uv action to v10 (#1031)c34d9bbUpdate dependency django to ==6.1.* (#1023)762c2d1Lock file maintenance (#1028)135195bUpdate dependency pre-commit to v4.6.2 (#1027)41decd6[pre-commit.ci] pre-commit autoupdate (#1026)f5ced24Remove coreapi/coreschema from stubs (DRF 3.17+) (#1025)b7ef8fbUpdate dependency djangorestframework to v3.18.0 & create new allowlist (#1024)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)