The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog check
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 1/5
- Thời gian dự kiến
- Dưới một giờ
- Mức phù hợp với người mới
- 82/100
Hướng nghiên cứu
Đọc .github/workflows/changelog.yml, đặc biệt là điều kiện của job changelog ở các dòng 20–23, rồi so sánh với phần loại trừ bot trong .github/workflows/check-links.yml. Thêm phần loại trừ actor Dependabot được mô tả trong issue, sau đó xác nhận workflow bỏ qua bước kiểm tra changelog đối với các pull request của Dependabot, đồng thời giữ nguyên các điều kiện hiện tại cho những sự kiện và actor khác.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Python
- Star
- 2.7k
- Fork
- 1k
- Merge trung bình
- 3 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 41
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của open-telemetry/opentelemetry-python
-
W3CBaggagePropagator.extract ignores all but the first baggage headerCó thể đã có người làm @knowprasad đã nhận 3 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
open-telemetry/opentelemetry-python#5811 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Delta exponential histogram never goes back to the maximum scale after a wide-range intervalCó thể đã có người làm @inchang-ing đã nhận 25 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
open-telemetry/opentelemetry-python#5716 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
open-telemetry/opentelemetry-python#5700 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Tests in test_metric_reader_storage.py assert on process-global mock state instead of on the storage under testCó thể đã có người làm @ocelotl đã nhận 47 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
open-telemetry/opentelemetry-python#5638 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
`SpanProcessor.on_end` exceptions escape cleanup and replace application exceptionsCó thể đã có người làm @somuai đã nhận 51 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
open-telemetry/opentelemetry-python#5624 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của open-telemetry/opentelemetry-python
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cuga-project/cuga-agent#1020 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
microsoft/playwright#43640 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
stac-utils/stac-fastapi-elasticsearch-opensearch#965 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
OneToOne.update rejects no-argument and keyword-only callsCó thể đã có người làm @Gambit-Checkmate đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 19 ngày