Skip to content

ci: Watch cargo deps with dependabot #355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
leongdl wants to merge 1 commit into
base: mainline
Choose a base branch
from
Open

ci: Watch cargo deps with dependabot #355

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions .github/dependabot.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,36 @@ updates:
update-types:
- "minor"
- "patch"
- package-ecosystem: "cargo"
directory: "/" # Workspace root; rust-bindings is discovered as a member
schedule:
interval: "weekly"
day: "monday"
commit-message:
prefix: "chore(deps):"
# openjd-* minor bumps get a PR each: they are 0.x, where cargo treats a
# minor as breaking, and they carry the API surface these bindings wrap.
# Everything else is grouped — tokio, uuid and serde_json are 1.x, where a
# minor is additive, and transitive Cargo.lock bumps are noise.
#
# Every cargo PR needs `scripts/check_third_party_licenses.sh --update`
# committed onto its branch: that check renders crate versions from
# Cargo.lock and dependabot cannot regenerate it.

@github-actions github-actions Bot Sep 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment documents a step Dependabot cannot perform, which means every cargo PM this config opens will land with a failing required check and, per .github/workflows/auto_approve.yml, an automatic approval on top of it.

The chain:

  1. A cargo bump (including a transitive-only Cargo.lock bump) changes Cargo.lock.
  2. third_party_licenses in .github/workflows/rust_quality.yml runs scripts/check_third_party_licenses.sh in verify mode, which renders crate versions from Cargo.lock and diffs against the committed THIRD-PARTY-LICENSES.txt — exit 1 on any drift.
  3. Dependabot never runs that script, so the job fails on essentially every cargo PR.
  4. auto_approve.yml triggers on any pull_request where github.actor == dependabot[bot] with no gate on check status or update type, so the PR gets approved regardless.

An approved PR sitting on a red check is a bad steady state for a repo where THIRD-PARTY-LICENSES.txt ships with every release: the failure becomes routine noise, and routine noise is what gets clicked past. Since the Python pip ecosystem block above also feeds the same script (via pyproject.toml [project.dependencies]), this is pre-existing for pip bumps, but adding cargo makes it the common case rather than the rare one.

Worth resolving before enabling this, rather than relying on the comment being read. Options:

  • A workflow on pull_request restricted to github.actor == dependabot[bot] that runs scripts/check_third_party_licenses.sh --update and pushes the result onto the Dependabot branch, so the check goes green on its own.
  • Or, if manual regeneration is genuinely the intended workflow, note that expectation in CONTRIBUTING.md/DEVELOPMENT.md where a maintainer will actually see it, and consider gating auto_approve.yml so it does not approve PRs whose checks have not passed.

groups:
# Matched first, so an openjd-* patch groups here and only minors reach
# the exclusion below. Majors match no group and so get a PR each.
cargo-patch:
patterns:
- "*"
update-types:
- "patch"
cargo-minor:
patterns:
- "*"
exclude-patterns:
- "openjd-*"

@github-actions github-actions Bot Sep 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "0.x minor = breaking" rationale used to exclude openjd-* applies to most of the other direct dependencies too, but they are not excluded.

From rust-bindings/Cargo.toml, the direct deps are:

  • 1.x (minor is additive): tokio, uuid, serde_json, log
  • 0.x (cargo treats minor as breaking): pyo3 = "0.29", pyo3-log = "0.13", pyo3-stub-gen = "0.23", windows = "0.62"

The comment above justifies grouping with "tokio, uuid and serde_json are 1.x, where a minor is additive", which is true for those three but silently mis-describes the four 0.x crates. As written, cargo-minor will bundle a pyo3 0.29 → 0.30 bump — which is a breaking API change and also moves the abi3 / extension-module surface and the pyo3-stub-gen compatibility pairing — into one PR alongside unrelated bumps like windows 0.62 → 0.63. That is the exact situation the openjd-* exclusion exists to avoid, and it makes the PR harder to review and to revert in isolation.

Consider either widening the exclusion, e.g.

        exclude-patterns:
          - "openjd-*"
          - "pyo3*"
          - "windows"

(pyo3 and pyo3-stub-gen are version-coupled, so if they should move together they are better in their own small group than in the catch-all), or updating the comment to state explicitly that 0.x breaking bumps other than openjd-* are intentionally grouped.

update-types:
- "minor"
- package-ecosystem: "github-actions"
directory: "/" # Location of package manifests
schedule:
Expand Down
Loading