Bump django-stubs from 6.0.7 to 6.1.0 - #2265
Open
dependabot[bot] wants to merge 1 commit into
Open
Conversation
Bumps [django-stubs](https://github.com/typeddjango/django-stubs) from 6.0.7 to 6.1.0. - [Release notes](https://github.com/typeddjango/django-stubs/releases) - [Commits](typeddjango/django-stubs@6.0.7...6.1.0) --- updated-dependencies: - dependency-name: django-stubs dependency-version: 6.1.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Review SummaryThis is a routine Dependabot bump of Code quality / best practices: N/A — pure version pin bump, follows the existing pinning convention ( Potential bugs: None expected from the stubs bump itself, but per the changelog this release includes "Support custom arguments in queryset update methods" and "Explicit through default manager" — these change how mypy type-checks certain Django ORM patterns ( Performance: No runtime impact — stubs are type-check-time only, not shipped in production. Security: No security concerns; this is a well-known, actively maintained typeddjango project. Test coverage: N/A for this change. Recommend letting CI (which runs pre-commit/mypy) confirm the bump is clean before merging, per this repo's baseline commit rule of "make sure typescript compiles and pre-commits pass before committing new code" (analogous mypy check applies here). Safe to merge once CI 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 django-stubs from 6.0.7 to 6.1.0.
Commits
2ec3fd3Version 6.1.0 (#3589)5868773Update int128/hide-comment-action action to v1.69.0 (#3588)e888491Support custom arguments in queryset update methods (#3586)ffd15ca[pre-commit.ci] pre-commit autoupdate (#3583)1af6dcfUpdate int128/hide-comment-action action to v1.68.0 (#3582)709e864Update dependency ty to v0.0.69 (#3580)5da937cUpdate dependency ty to v0.0.68 (#3579)7afd2daUpdate dependency ty to v0.0.67 (#3578)07e22f2Explicit through default manager (#3576)db47c3bUpdate dependency django to v5.2.17 (#3575)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)