deps: tidy the example module and let Dependabot see it - #15
Merged
Conversation
CI on main is red. The github-actions bump in #13 also moved the root go.mod, but examples/provider is a separate module — by design, since it exists to prove pkg/ builds from outside the main one — so its pinned versions were left behind. The CI step added in #14 runs `go mod tidy` there and fails on any diff, which is exactly what happened. Tidying it fixes today. The reason it happened is that Dependabot resolves a directory, not a repository, and its gomod entry only listed "/" — so the nested module goes stale silently on every root bump, and every future dependency PR would turn main red the same way. Adding /examples/provider to that entry fixes the cause. This is the same failure mode the config's own composite-action note already describes: "each one's directory has to be listed, or the SHAs pinned inside it go stale silently while the workflows around it stay current." The dependency versions here are Dependabot's from #13, not chosen by this change — `go mod tidy` resolves them from the root module's graph.
Dependency ReviewThe following issues were found:
License Issuesexamples/provider/go.mod
OpenSSF Scorecard
Scanned Files
|
There was a problem hiding this comment.
Pull request overview
Fixes CI failures caused by a stale nested Go module in examples/provider by aligning its dependency graph with the root module and ensuring Dependabot keeps it updated going forward.
Changes:
- Ran
go mod tidyfor the standaloneexamples/providermodule, updating its indirect dependency versions and checksums. - Updated
.github/dependabot.ymlto include/examples/providerin the Go module update scope (viadirectories) so future root bumps don’t leave the nested module behind.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
examples/provider/go.mod |
Updates indirect dependency versions after tidying the nested module. |
examples/provider/go.sum |
Refreshes module checksums consistent with the updated go.mod. |
.github/dependabot.yml |
Adds /examples/provider to Dependabot’s Go module directories to prevent future drift/CI breakage. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
CI on
mainis currently red. This fixes it, and fixes the reason it happened.examples/provideris a separate Go module — deliberately, since it exists to provepkg/builds from outside the main one (#14). The github-actions bump in #13 also moved the rootgo.mod, but a nested module has its own pins, so it was left behind. The CI step added in #14 runsgo mod tidythere and fails on any diff, which is exactly what it did:Two changes:
examples/provider— fixes today. The versions are Dependabot's from ci: bump the github-actions group across 1 directory with 4 updates #13, not chosen here;go mod tidyresolves them from the root module's graph./examples/providerto Dependabot'sgomodentry — fixes the cause. Dependabot resolves a directory, not a repository, and that entry only listed/. Without this, the nested module goes stale silently on every root bump and every future dependency PR turnsmainred the same way.This is the same failure mode the config's own composite-action note already warns about, one entry below:
Checklist
go mod tidyis a no-op,go build ./...,go vet ./...,gofmt -l -s .prints nothing,go test -race -covermode=atomic ./...,golangci-lint rundocs/specifications/document in this same PR (no spec-visible behavior changes — dependency pins and CI config only)pkg/*/proto/v1/—.protochanges made inapi/and regenerated withbuf generate(no proto changes)internal/packages includeREADME.md+CLAUDE.mdin the same commit (no new packages)bin/Also verified: the failing CI step reproduced locally verbatim (
go mod tidy && git diff --exit-code && go build && go vet && go testinsideexamples/provider) and now passes, and.github/dependabot.ymlstill parses with the gomod entry resolving to['/', '/examples/provider'].Notes for reviewers
Worth a look at whether any other nested module could appear later and hit this again — right now
examples/provideris the only one, and the added comment says why each module needs its own entry rather than just listing this one.The bump itself is untouched: I did not choose or pin any version here, only let
tidypropagate what #13 already landed at the root.