[ocelotl]

The counterpart of this change for opentelemetry-python-contrib is open-telemetry/opentelemetry-python-contrib#5236. The argument there is not the argument here, because this repository already has a Dependabot configuration and also runs Renovate, so please do not read the two as copies of each other.

• Definitions
• What this repository has today
• The gap
• Evidence in this repository
• The change
• Why open-pull-requests-limit is 0
• The cooldown, which does nothing here
• What this does not do
• What I could and could not verify

Definitions

• A security update is a pull request Dependabot opens by itself to resolve a published advisory affecting a dependency of this repository. Security updates run for every ecosystem Dependabot can parse, whether or not .github/dependabot.yml mentions that ecosystem.

• A version update is a pull request Dependabot opens on a schedule to move a dependency to its latest release, regardless of any advisory. Version updates run only for an ecosystem that .github/dependabot.yml declares, which today is github-actions and nothing else.

• A group is a groups entry in .github/dependabot.yml that tells Dependabot to collect several updates into one pull request instead of opening one per dependency. Its applies-to key chooses which kind it collects, and common/lib/dependabot/dependency_group.rb:52 in dependabot-core shows the default is version-updates, so collecting security updates requires saying so explicitly.

• A cooldown is a number of days Dependabot waits after a release is published before proposing it, set by cooldown.default-days. Omitting the key does not mean zero, because Dependabot's implicit default is three days.

What this repository has today

.github/dependabot.yml declares one ecosystem, github-actions, with a weekly schedule, a seven day cooldown and a group matching *. That entry works. #5817, "bump the github-actions group across 1 directory with 11 updates", is what it produces, and this change leaves it untouched.

.github/renovate.json5 also exists, and Renovate performs the Python version updates here: lockFileMaintenance on uv.lock weekly, and a pip-compile manager for the *-requirements.oldest.txt and *-requirements.latest.txt files. That matters for the shape of this change and is the subject of Why open-pull-requests-limit is 0.

The gap

Neither of those covers Python security updates. Dependabot opens those regardless of configuration, and with no uv or pip entry to group them, it opens one per advisory per manifest.

There are 126 open Dependabot alerts. The largest counts are urllib3 at 43, Pygments at 12, thrift at 9, requests at 8, then django, idna and protobuf at 7 each.

Evidence in this repository

114 Dependabot pull requests have been opened over the life of this repository and 45 merged. 30 of the 114 concern a single package rather than the github-actions group, and in two cases the same package produced two simultaneous pull requests that a group would have collapsed into one.

package	pull requests	what differs	alerts open today
thrift	#5611, #5615	directory only, both bump 0.13.0 to 0.24.0	9
protobuf	#4884, #4896	directory, and the target version	7

In both cases the two directories are docs/examples/fork-process-model/flask-gunicorn and docs/examples/fork-process-model/flask-uwsgi, each with its own requirements.txt naming the same package.

thrift is the case worth dwelling on, because it is the one that cost something. #5611 and #5615 were both closed by the stale workflow on 2026-10-02, which told Dependabot not to offer 0.24.0 again, and thrift has had 9 alerts open ever since. One pull request instead of two would have halved the review needed to avoid that, and #5827 addresses the other half.

I checked the two other same-package overlaps I found and they are not duplicates, so I am not counting them. werkzeug #4835 and #4873, and virtualenv #5721 and #5810, are each Dependabot superseding its own earlier pull request with a newer target in the same file. Grouping would not change those.

The change

Two new entries in .github/dependabot.yml, in one commit, adding no other file. The uv entry:

  - package-ecosystem: uv
    directory: /
    cooldown:
      default-days: 7
    open-pull-requests-limit: 0
    groups:
      python-security:
        applies-to: security-updates
        patterns:
          - "*"
    schedule:
      interval: weekly

The pip entry is the same with directories: [/**]. Both ecosystems are needed because the Python manifests are split between them: uv.lock at the root is the uv ecosystem, and the 49 requirements-style .txt files are the pip ecosystem. Dependabot's own labels show the split, with python:uv on #5765, #5800 and #5810 and no such label on the docs/examples pull requests. Both values are registered ecosystems in dependabot-core, uv at uv/lib/dependabot/uv/package_manager.rb:11.

The key order inside each entry follows the existing github-actions entry rather than the order used in the contrib pull request.

Why open-pull-requests-limit is 0

Declaring an ecosystem normally switches on version updates for it, and that would be wrong here, because Renovate already performs them. Two bots proposing the same bump is worse than the problem this change fixes.

open-pull-requests-limit: 0 prevents it. Security updates are unaffected, and GitHub's reference for .github/dependabot.yml says so directly: "Security update pull requests are subject to a separate, fixed limit of 10 open pull requests, which cannot be configured using open-pull-requests-limit."

So after this merges, Dependabot proposes exactly what it proposes today for Python, grouped, and Renovate keeps doing the rest.

The cooldown, which does nothing here

Both new entries carry a seven day cooldown and it has no effect, which I would rather state than let it read as a judgement about release stability.

GitHub applies a cooldown only to version updates: "The cooldown option is only available for version updates, not security updates." The version updates it could delay are disabled by open-pull-requests-limit: 0. It is present because the dependabot-cooldown audit in zizmor requires seven days, treats the implicit three day default as insufficient, and does not distinguish the two kinds of update. zizmor runs on every pull request here through .github/workflows/zizmor.yml, and the existing github-actions entry already carries the same key for the same reason, so omitting it on the new entries would raise two medium findings.

.github/zizmor.yml exists and could instead carry a rules.dependabot-cooldown entry. I did not take that route, because an inert setting is cheaper to read than a suppression that has to be justified again later.

What this does not do

It does not reopen anything. thrift's 9 alerts and protobuf's 7 stay open after this merges, because Dependabot has already been told not to offer those releases. #5611 and #5615 need reopening by hand, or the pins raised directly.

It does not touch Renovate, the existing github-actions entry, or any workflow.

What I could and could not verify

Verified:

• The file parses as YAML and validates against the published Dependabot schema, fetched from https://raw.githubusercontent.com/SchemaStore/schemastore/master/src/schemas/json/dependabot-2.0.json, with no errors.
• zizmor 1.31.1 reports no findings against the edited file. I also confirmed it reports none against the current file, so this change introduces no finding and removes none.
• uv and pip are real package-ecosystem values, and applies-to is a real groups key defaulting to version-updates, both checked against the dependabot-core source rather than from memory.
• build(deps): bump thrift from 0.13.0 to 0.24.0 in /docs/examples/fork-process-model/flask-gunicorn #5611 and build(deps): bump thrift from 0.13.0 to 0.24.0 in /docs/examples/fork-process-model/flask-uwsgi #5615 carry identical version bumps and differ only in directory, and build(deps): bump protobuf from 3.20.3 to 7.34.0rc1 in /docs/examples/fork-process-model/flask-gunicorn #4884 and build(deps): bump protobuf from 3.20.3 to 5.29.6 in /docs/examples/fork-process-model/flask-uwsgi #4896 differ in directory and target. I read the file lists of all four through the API.

Not verified: Dependabot reads .github/dependabot.yml only from the default branch, so none of this takes effect, and none of its runtime behaviour can be observed, until it is merged. In particular I could not confirm how directories: [/**] on the pip entry interacts with the uv entry at /, since both could match a manifest at the root. If that double-processes anything it would show up as duplicate grouped pull requests rather than as missed updates, and the fix would be to narrow the pip directories.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-10-26 20:58 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.