viirya opened a new pull request, #28:
URL: https://github.com/apache/spark-connect-gateway/pull/28
### What changes were proposed in this pull request?
Add `.github/dependabot.yml` so dependabot raises coupled crate families in
one
PR instead of one crate at a time, and skips patch-level updates.
Three groups:
| group | crates | why they are coupled |
|---|---|---|
| `opentelemetry` | 7 | the `opentelemetry*` family plus
`tracing-opentelemetry`, whose version is offset by one minor (0.33 tracks
opentelemetry 0.32) |
| `tonic-prost` | 6 | `tonic-prost` depends on `tonic` and `prost`,
`tonic-health` on `tonic` and `tonic-prost`, and `opentelemetry-proto` on
`tonic` and `prost` as well |
| `kube` | 2 | `kube` depends on `k8s-openapi`, whose version selects the
Kubernetes API version its generated types target |
Patch-level updates are ignored for every dependency.
### Why are the changes needed?
Crates in these families share types across their public APIs, so bumping one
member on its own leaves two major versions of the family in the dependency
graph
and the traits stop lining up. A PR in that state cannot be made green by
rerunning it — it is unmergeable by construction.
That is not hypothetical. Dependabot opened #8 to bump `opentelemetry_sdk`
alone;
it was closed as unmergeable, and the upgrade that actually worked
(SPARK-59548, #27) had to move all seven `opentelemetry*` crates **and**
`tracing-opentelemetry` together. Without grouping, dependabot will keep
opening
that same PR every time any one of these crates releases.
Patch updates are ignored because dependencies here are pinned by minor and
`Cargo.lock` is committed, so patch PRs are noise — a real patch pickup rides
along with the next minor bump or a deliberate `cargo update`. Happy to drop
that
part if you would rather see them.
### Does this PR introduce _any_ user-facing change?
No. Dependabot configuration only; no dependency versions change here and no
code
is touched.
### How was this patch tested?
A config file is only useful if it takes effect, and a bad `dependabot.yml`
is
ignored silently rather than reported, so I checked it three ways instead of
eyeballing it.
**The patterns match the intended crates and nothing else.** Matched with
`fnmatch` against the real names in `[workspace.dependencies]`:
```
opentelemetry: opentelemetry, opentelemetry-otlp, opentelemetry-proto,
opentelemetry-semantic-conventions, opentelemetry-stdout,
opentelemetry_sdk, tracing-opentelemetry (7)
tonic-prost: prost, prost-types, tonic, tonic-health,
tonic-prost, tonic-prost-build (6)
kube: k8s-openapi, kube (2)
```
Note `opentelemetry_sdk` needs the `opentelemetry_*` pattern separately from
`opentelemetry-*` — the underscore would otherwise be missed.
**Nothing is over-matched.** `tracing` and `tracing-subscriber` stay
ungrouped, as
they should: they carry no version coupling to OpenTelemetry, and a
`tracing-*`
pattern would have swept them in and needlessly held their updates behind the
OpenTelemetry family.
**The coupling itself was verified, not assumed** — each relationship above
was
read out of `Cargo.lock`'s dependency lists rather than inferred from the
crate
names. That is how the `kube` / `k8s-openapi` pair was found; it was not in
the
original scope.
The schema was also checked against dependabot v2's permitted keys for
`updates`,
`groups` and `ignore` entries: no unknown fields.
### Was this patch authored or co-authored using generative AI tooling?
Yes, co-authored with Claude Code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
