fix(authbridge): Raise the workspace Go directive to 1.26.5 - #796
Conversation
Dependency updates that raise a module's minimum Go version fail the
Go CI (authlib) job. That job is the only one which reads go.work --
the cmd/* matrix and dependabot-tidy both set GOWORK=off -- so with
go.work pinned at 1.26.4 any module requiring >= 1.26.5 errors:
go: module . listed in go.work file requires go >= 1.26.5,
but go.work lists go 1.26.4
and it cascades to every module in the workspace, making the failure
look broader than the one dependency that caused it.
Dependabot only edits the directory it is updating, so it can never
fix go.work itself; the failure recurs on every toolchain-raising
bump. Currently blocking #771 (bifrost/core 1.7.0 -> 1.7.13).
Modules stay at go 1.26.4. go.work only needs to be >= the highest
module directive, so raising it alone is sufficient and stays valid
once modules move to 1.26.5. The authlib job leaves GOTOOLCHAIN at
its default (auto), so it fetches the newer toolchain as needed.
Signed-off-by: Hai Huang <huang195@gmail.com>
Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe pull request updates the declared Go version from 1.26.4 to 1.26.5 in seven modules. No dependencies, replace directives, or exported declarations change. ChangesGo module version alignment
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This is a localized Go version alignment change with no actionable merge-blocking risk remaining beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 golangci-lint (2.12.2)level=error msg="Running error: context loading failed: no go files to analyze: running Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bumping go.work alone does not work, and the reason is worth recording: actions/setup-go exports GOTOOLCHAIN=local itself and installs the version named by go-version-file (authbridge/authlib/go.mod). A toolchain pinned at 1.26.4 and forbidden from upgrading can never satisfy a go.work that asks for 1.26.5: go: ../go.work requires go >= 1.26.5 (running go 1.26.4; GOTOOLCHAIN=local) So the module directives have to move together with go.work: authlib's is what selects the CI toolchain, and every module that replaces authlib must not declare an older Go than authlib does. All seven workspace modules go to 1.26.5 in one step. This is not speculative -- #771 (bifrost/core 1.7.0 -> 1.7.13) already raises four of them, and Dependabot cannot touch go.work, so the split would recur on every toolchain-raising bump. Doing it deliberately keeps GOTOOLCHAIN=local hermetic and makes #771 a clean rebase. Checked: the CI matrix covers only proxy and envoy, both of which read their own go.mod with GOWORK=off; dependabot-tidy reads the same authlib/go.mod and follows automatically; the cmd Dockerfiles use golang:1.26-alpine, and 1.26.7 is released. Signed-off-by: Hai Huang <huang195@gmail.com> Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Problem
Any dependency update that raises a module's minimum Go version fails
Go CI (authlib), and reports it as four broken modules rather than one. From#771 (
bifrost/core1.7.0 → 1.7.13):go-ci-authlibis the only Go job that readsgo.work— thecmd/*matrix(
ci.yaml:86) anddependabot-tidy(dependabot-tidy.yml:33) both setGOWORK: "off"— which is why one dependency bump surfaces as a single checkfailing about four modules.
Dependabot only edits the directory it is updating, and
authbridge/go.worksitsoutside every configured
gomoddirectory, so no Dependabot PR can fix it. Leftalone this recurs on every toolchain-raising bump.
Why
go.workalone is not enoughThe first attempt here bumped only
go.work, and CI rejected it:actions/setup-goexportsGOTOOLCHAIN=localitself — it is absent fromci.yaml, which makes it easy to assume the defaultauto— and installs theversion named by
go-version-file: authbridge/authlib/go.mod. A toolchain pinnedat 1.26.4 and forbidden from upgrading can never satisfy a
go.workasking for1.26.5.
So the module directives must move with
go.work:authlib/go.modis whatselects the CI toolchain, and no module that
replaces authlib may declare anolder Go than authlib.
Change
go 1.26.4→go 1.26.5, one line each, acrossgo.workand all sevenworkspace modules. No
toolchaindirectives exist in any of them, and nogo.sumis affected.This is not speculative: #771 already raises four of the seven, so the floor is
moving regardless. Doing it deliberately keeps
GOTOOLCHAIN=localhermetic andturns #771's rebase into a no-op on these lines.
Collateral checked
Go CI (authlib)authlib/go.mod;go.worksatisfiedGo CI (authbridge proxy/envoy)go.mod;GOWORK: "off"dependabot-tidyauthlib/go.mod, soGOTOOLCHAIN: localstays satisfiedcmd/*Dockerfilesgolang:1.26-alpine; 1.26.7 is releasedabctl,cpex,praxis,storage/redisreplaceauthlib so they move with itDemo modules are untouched — they are standalone (
golang:1.24-alpine) and do notreplace authlib.
Unblocks
bifrost/core1.7.0 → 1.7.13 (rebase after this merges)Assisted-By: Claude Code
Summary by CodeRabbit