Catch lang-SDK Go example module drift before it reaches main - #70568
Merged
Conversation
kubernetes-tests/lang_sdk/go_example is a separate Go module that resolves the SDK through a `replace` onto ../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside /go-sdk, and Dependabot bumps exactly one module per PR. The blast radius is what makes this worth guarding. Go refuses to build an inconsistent module, so once such a bump merges, "Kubernetes tests / K8S Lang-SDK" fails at the Build Go bundle step on every pull request until someone notices and tidies the module by hand — not just on the PR that caused it. Dependabot security updates do not consult .github/dependabot.yml, so no per-directory configuration prevents this, and a second Dependabot PR for the example module would merge at a different time and leave main red in between. The drift has to fail the bump PR itself. The check is `go mod tidy -diff` in the example module: it asks exactly the question the failing CI step asks, never writes to the working tree, and exits non-zero when the module is untidy.
potiuk
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jason810496 and
jscheffl
as code owners
July 27, 2026 21:28
shahar1
approved these changes
Jul 27, 2026
jason810496
reviewed
Jul 28, 2026
jason810496
left a comment
Member
There was a problem hiding this comment.
Yes, that is exactly what I thought about to prevent further drift, thanks.
Static checks run on a runner whose preinstalled toolchains are deleted to free disk space before prek starts, so the check could never find `go` there and failed on every run. Asking prek for the toolchain is how the Go SDK's own tidy hook already gets one, and it pins the same version everywhere.
Contributor
Backport successfully created: v3-3-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
github-actions Bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Jul 28, 2026
…main (apache#70568) * Catch lang-SDK Go example module drift before it reaches main kubernetes-tests/lang_sdk/go_example is a separate Go module that resolves the SDK through a `replace` onto ../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside /go-sdk, and Dependabot bumps exactly one module per PR. The blast radius is what makes this worth guarding. Go refuses to build an inconsistent module, so once such a bump merges, "Kubernetes tests / K8S Lang-SDK" fails at the Build Go bundle step on every pull request until someone notices and tidies the module by hand — not just on the PR that caused it. Dependabot security updates do not consult .github/dependabot.yml, so no per-directory configuration prevents this, and a second Dependabot PR for the example module would merge at a different time and leave main red in between. The drift has to fail the bump PR itself. The check is `go mod tidy -diff` in the example module: it asks exactly the question the failing CI step asks, never writes to the working tree, and exits non-zero when the module is untidy. * Let prek provide the Go toolchain for the tidy check Static checks run on a runner whose preinstalled toolchains are deleted to free disk space before prek starts, so the check could never find `go` there and failed on every run. Asking prek for the toolchain is how the Go SDK's own tidy hook already gets one, and it pins the same version everywhere. (cherry picked from commit bce20ff) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
aws-airflow-bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Jul 28, 2026
…main (apache#70568) * Catch lang-SDK Go example module drift before it reaches main kubernetes-tests/lang_sdk/go_example is a separate Go module that resolves the SDK through a `replace` onto ../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside /go-sdk, and Dependabot bumps exactly one module per PR. The blast radius is what makes this worth guarding. Go refuses to build an inconsistent module, so once such a bump merges, "Kubernetes tests / K8S Lang-SDK" fails at the Build Go bundle step on every pull request until someone notices and tidies the module by hand — not just on the PR that caused it. Dependabot security updates do not consult .github/dependabot.yml, so no per-directory configuration prevents this, and a second Dependabot PR for the example module would merge at a different time and leave main red in between. The drift has to fail the bump PR itself. The check is `go mod tidy -diff` in the example module: it asks exactly the question the failing CI step asks, never writes to the working tree, and exits non-zero when the module is untidy. * Let prek provide the Go toolchain for the tidy check Static checks run on a runner whose preinstalled toolchains are deleted to free disk space before prek starts, so the check could never find `go` there and failed on every run. Asking prek for the toolchain is how the Go SDK's own tidy hook already gets one, and it pins the same version everywhere. (cherry picked from commit bce20ff) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
potiuk
added a commit
that referenced
this pull request
Jul 28, 2026
…main (#70568) (#70624) * Catch lang-SDK Go example module drift before it reaches main kubernetes-tests/lang_sdk/go_example is a separate Go module that resolves the SDK through a `replace` onto ../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside /go-sdk, and Dependabot bumps exactly one module per PR. The blast radius is what makes this worth guarding. Go refuses to build an inconsistent module, so once such a bump merges, "Kubernetes tests / K8S Lang-SDK" fails at the Build Go bundle step on every pull request until someone notices and tidies the module by hand — not just on the PR that caused it. Dependabot security updates do not consult .github/dependabot.yml, so no per-directory configuration prevents this, and a second Dependabot PR for the example module would merge at a different time and leave main red in between. The drift has to fail the bump PR itself. The check is `go mod tidy -diff` in the example module: it asks exactly the question the failing CI step asks, never writes to the working tree, and exits non-zero when the module is untidy. * Let prek provide the Go toolchain for the tidy check Static checks run on a runner whose preinstalled toolchains are deleted to free disk space before prek starts, so the check could never find `go` there and failed on every run. Asking prek for the toolchain is how the Go SDK's own tidy hook already gets one, and it pins the same version everywhere. (cherry picked from commit bce20ff) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
Aug 5, 2026
…main (#70568) (#70624) * Catch lang-SDK Go example module drift before it reaches main kubernetes-tests/lang_sdk/go_example is a separate Go module that resolves the SDK through a `replace` onto ../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside /go-sdk, and Dependabot bumps exactly one module per PR. The blast radius is what makes this worth guarding. Go refuses to build an inconsistent module, so once such a bump merges, "Kubernetes tests / K8S Lang-SDK" fails at the Build Go bundle step on every pull request until someone notices and tidies the module by hand — not just on the PR that caused it. Dependabot security updates do not consult .github/dependabot.yml, so no per-directory configuration prevents this, and a second Dependabot PR for the example module would merge at a different time and leave main red in between. The drift has to fail the bump PR itself. The check is `go mod tidy -diff` in the example module: it asks exactly the question the failing CI step asks, never writes to the working tree, and exits non-zero when the module is untidy. * Let prek provide the Go toolchain for the tidy check Static checks run on a runner whose preinstalled toolchains are deleted to free disk space before prek starts, so the check could never find `go` there and failed on every run. Asking prek for the toolchain is how the Go SDK's own tidy hook already gets one, and it pins the same version everywhere. (cherry picked from commit bce20ff) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
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
3 participants
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.
Follow-up to #70561, which cleaned up the drift by hand. This stops the next Go bump from doing it again.
kubernetes-tests/lang_sdk/go_exampleis a separate Go module that resolves the SDK through areplaceonto../../../go-sdk, so it carries its own copy of the SDK's indirect requirements. Nothing re-tidies it when a dependency moves inside/go-sdk, and Dependabot bumps exactly one module per PR — #70226 movedgoogle.golang.org/grpc1.79.3 → 1.82.1 in/go-sdkonly.What makes it worth guarding is the blast radius: Go refuses to build an inconsistent module, so once such a bump merges,
Kubernetes tests / K8S Lang-SDKfails at the "Build Go bundle" step on every pull request until someone notices — not just on the PR that caused it.Config can't prevent this. Dependabot security updates ignore
.github/dependabot.ymlentirely (which today has nogomodentry at all), and a second Dependabot PR for the example module would merge at a different time and leavemainred in between. The drift has to fail the bump PR itself.The check is
go mod tidy -diffin the example module — exactly the question the failing CI step asks, it never writes to the working tree, and it exits non-zero when the module is untidy. It runs only when either module'sgo.mod/go.sumchanges, which is sufficient: any new requirement in the SDK necessarily lands ingo-sdk/go.modfirst.Verified against the real regression. On
mainas it stands:and the reported diff is byte-for-byte the change #70561 makes. After applying that tidy, the hook exits 0.
This PR's own static checks will be red until #70561 merges
That is the hook working, not a defect —
mainis currently untidy, so the check it adds correctly fails. The commit was made withSKIP=check-go-example-mod-tidyfor the same reason. Once #70561 lands, this goes green with no change here; happy to rebase onto it instead if you'd rather have one green PR.Not addressed: the existing
go-mod-tidyhook ingo-sdk/.pre-commit-config.yamlistypes: [go], so it does not fire ongo.mod/go.sumchanges either. That has not bitten us because Dependabot tidies the module it bumps, but it is the same gap one level up.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines