The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog check
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 82/100
Research direction
Read .github/workflows/changelog.yml, especially the changelog job condition at lines 20–23, and compare it with the bot exclusion in .github/workflows/check-links.yml. Add the Dependabot actor exclusion described in the issue, then confirm the workflow skips the changelog check for Dependabot pull requests while retaining its current conditions for other events and actors.
Written by the indexing model from the issue text.
Description
Every pull request opened by dependabot[bot] fails the changelog check, because the job producing that check excludes otelbot[bot] and says nothing about dependabot[bot]. All 5 open Dependabot pull requests are failing it right now, the oldest since 1 October 2026. Renovate does not hit this, because .github/renovate.json5:11-13 applies the Skip Changelog label to its own pull requests and Dependabot has no equivalent.
This is the same defect as open-telemetry/opentelemetry-python-contrib#5226, fixed there by open-telemetry/opentelemetry-python-contrib#5227.
- Definitions
- Notation
- What the workflow does today
- What it costs today
- Why the fix does not belong in the Dependabot configuration
- Proposed fix
Definitions
-
A changelog fragment is a file added under
.changelog/by a pull request, recording the user-visible change that pull request makes. The requirement is stated in.github/workflows/changelog.yml:1-3. -
The changelog check is the status check produced by the job named
changelogin.github/workflows/changelog.yml. It fails when a pull request targetingmainadds no changelog fragment. -
The Skip Changelog label is the GitHub label named
Skip Changelog. Applying it to a pull request makes the changelog check skip, through thecontainscall at.github/workflows/changelog.yml:22. -
The actor of a workflow run is the account GitHub reports as having triggered the run, which a workflow expression reads as
github.actor. For a pull request opened by Dependabot the actor isdependabot[bot], and for one opened by Renovate it isrenovate[bot]. -
A Dependabot version update is a pull request Dependabot opens to raise a dependency to its newest version, on the schedule of an entry under
updates:in.github/dependabot.yml. This repository declares exactly one such entry, for thegithub-actionsecosystem, at.github/dependabot.yml:6. -
A Dependabot alert is a notification that a distribution recorded in the dependency graph of a repository matches a published security advisory. It opens no pull request by itself. This repository has 109 open ones.
-
A Dependabot security update is a pull request Dependabot opens to raise a distribution named by a Dependabot alert to a version that the advisory records as patched. It is enabled per repository rather than per entry in
.github/dependabot.yml, so it is opened for ecosystems that file does not declare.For example, #5720 raises
urllib3from 2.7.0 to 2.8.0 inuv.lock, and the release notes it quotes are headedSecurity. No entry in.github/dependabot.ymlcoversuv.lock.
Notation
-
Fis the set of 5 open pull requests opened bydependabot[bot]whose changelog check has failed. -
Mis the set of 18 merged pull requests opened bydependabot[bot].
What the workflow does today
The condition of the changelog job, at .github/workflows/changelog.yml:20-23, is:
if: |
github.event_name != 'merge_group' &&
!contains(github.event.pull_request.labels.*.name, 'Skip Changelog')
&& github.actor != 'otelbot[bot]'
So the changelog check is skipped when the actor is otelbot[bot], and it runs when the actor is dependabot[bot].
Dependabot can satisfy the condition in neither of the two available ways. It does not write a changelog fragment, and it does not apply the Skip Changelog label to its own pull requests. The changelog check therefore fails on every Dependabot pull request and stays failed until a maintainer applies the Skip Changelog label by hand.
Renovate reaches the same outcome by the other branch of the condition. .github/renovate.json5:11-13 sets:
labels: [
"dependencies",
"Skip Changelog",
],
Every Renovate pull request therefore arrives already carrying the Skip Changelog label, and gh pr checks reports its changelog check as skipping. Checked on 25 October 2026 against #5794, #5780 and #5779.
The repository already spells the exclusion for Dependabot elsewhere. .github/workflows/check-links.yml:37 names both accounts, and has named dependabot[bot] since #2812 in July 2022:
if: ${{ github.actor != 'dependabot[bot]' && github.actor != 'otelbot[bot]' }}
The exclusion at .github/workflows/changelog.yml:23 arrived later, in #4685 in July 2025, and named only otelbot[bot].
What it costs today
Measured on 25 October 2026:
| Count | |
|---|---|
Open pull requests opened by dependabot[bot] |
5 |
...of those, with a failing changelog check, which is F |
5 |
| ...of those, carrying a hand-applied Skip Changelog label | 0 |
Merged pull requests opened by dependabot[bot], which is M |
18 |
...of M, carrying the Skip Changelog label |
18 |
The correlation runs in both directions with no exception. A Dependabot pull request merges once a maintainer labels it, and otherwise waits with a red check. Every member of M was labelled by hand, going back to #4463 in March 2025.
The oldest member of F is #5720, open since 1 October 2026. The other four are #5765, #5800, #5810 and #5817.
For comparison, 5 of the 20 most recent pull requests opened by otelbot[bot] carry the Skip Changelog label. The other 15 do not need it, because the exclusion at .github/workflows/changelog.yml:23 already covers them.
Why the fix does not belong in the Dependabot configuration
Copying the labels key of .github/renovate.json5:11-13 into .github/dependabot.yml looks like the symmetrical fix, and it does not cover the pull requests that are failing.
.github/dependabot.yml:6 declares one entry, for the github-actions ecosystem. Dependabot reads a labels key from the entry matching the ecosystem and directory of a pull request, so a labels key added there reaches a Dependabot version update for a workflow file and nothing else.
Four of the five members of F change uv.lock: #5720, #5765, #5800 and #5810. They are Dependabot security updates for an ecosystem no entry in .github/dependabot.yml declares, and they carry only the labels Dependabot applies by default, dependencies and python:uv. A labels key under the github-actions entry would leave all four still failing.
Covering them through .github/dependabot.yml would mean declaring a second entry for the Python ecosystem purely to carry a label, which turns on Dependabot version updates for every pinned Python distribution in the repository. Renovate already does that job, and .github/renovate.json5 is configured in detail to do it. The two would then open competing pull requests for the same distributions.
The volume argues the same way. 109 Dependabot alerts are open, and each one that Dependabot can patch arrives as a Dependabot security update with a red changelog check, waiting for a maintainer to apply the Skip Changelog label by hand.
Proposed fix
Add dependabot[bot] to the condition at .github/workflows/changelog.yml:23, so that it names the same two accounts .github/workflows/check-links.yml:37 already names:
if: |
github.event_name != 'merge_group' &&
!contains(github.event.pull_request.labels.*.name, 'Skip Changelog')
&& github.actor != 'otelbot[bot]'
&& github.actor != 'dependabot[bot]'
A Dependabot pull request raises a pinned version in a requirements file, in a pyproject.toml, in uv.lock or in a workflow file. It publishes no distribution and alters the behaviour of no released one, which is the case the Skip Changelog label exists for. The exclusion therefore produces the same outcome the maintainers already produce by hand, 18 times out of 18.
It also covers every ecosystem at once, including the ones .github/dependabot.yml does not declare, which is what the Dependabot security updates in F need.
I will open a pull request with that one-line change.
- Dominant language
- Python
- Stars
- 2.7k
- Forks
- 1k
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 41
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-telemetry/opentelemetry-python
-
W3CBaggagePropagator.extract ignores all but the first baggage headerPossibly taken @knowprasad claimed this 3 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
open-telemetry/opentelemetry-python#5811 ·
Maintainers usually reply within 2 days
-
Delta exponential histogram never goes back to the maximum scale after a wide-range intervalPossibly taken @inchang-ing claimed this 25 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-python#5716 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
open-telemetry/opentelemetry-python#5700 · 1 comment ·
Maintainers usually reply within 2 days
-
Tests in test_metric_reader_storage.py assert on process-global mock state instead of on the storage under testPossibly taken @ocelotl claimed this 47 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-python#5638 ·
Maintainers usually reply within 2 days
-
`SpanProcessor.on_end` exceptions escape cleanup and replace application exceptionsPossibly taken @somuai claimed this 51 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
open-telemetry/opentelemetry-python#5624 ·
Maintainers usually reply within 2 days
All issues in open-telemetry/opentelemetry-python
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
yzhao062/awesome-auditable-ai#45 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
NVIDIA/flare-local-inference#90 ·
Maintainers usually reply within 1 day
-
area/streaming comp/gateway P2 platform/telegram type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#144897 ·
Maintainers usually reply within 1 day
-
request-theme
Difficulty 1/5 Under an hour Newbie friendliness 66/100
LizardByte/ThemerrDB#9575 ·
Maintainers usually reply within 1 day