build(collector): pin build toolchain to go1.26.7

[arein]

What

Adds a toolchain go1.26.7 directive to collector/go.mod. The go directive stays at 1.26.1, so the minimum Go version required of anyone importing this module does not change.

Why

collector/go.mod is the toolchain pin for released collector layers. .github/actions/build-collector-layer/action.yml runs actions/setup-go with go-version-file: collector/go.mod, and release-layer-collector.yml builds the published artifact through that action. That directive has been 1.26.1 across 0.22.0 and 0.23.0, so releases are built with go1.26.1.

Confirmed against the published layer-collector/0.23.0 amd64 asset (zip sha256 16d07443dd1b0059a16a3e62b1779d428a006e5f8de9232b37aebcee8935c838):

$ go version -m extensions/collector
extensions/collector: go1.26.1
        ...
        dep     golang.org/x/net        v0.57.0

go1.26.1 is affected by GO-2026-5026 / CVE-2026-39821 (Punycode handling in x/net/idna, vendored into the standard library and reachable through net/http), which is fixed in go1.26.6. As the build info above shows, the module's own golang.org/x/net is already v0.57.0, so the direct dependency is clear and only the stdlib copy is outstanding. Consumers scanning the layer see it as a go/stdlib finding.

To be clear, nothing here was overdue: 0.23.0 was built on 2026-08-01 and go1.26.6 was not tagged until 2026-08-13. There simply has not been a release since a patched toolchain existed. This is a nudge so the next one picks one up.

Independently reported in #2323.

Why a toolchain directive instead of bumping go

Bumping the go directive would also raise the minimum Go version required of importers of this module, which seemed like the wrong side effect for a build-time concern. A toolchain directive pins the build without touching that.

actions/setup-go is pinned at v7.0.0 (b7ad1dad31e06c5925ef5d2fc7ad053ef454303e) in all six places it appears in this repo, and at that exact revision parseGoVersionFile prefers toolchain over go:

// for backwards compatibility: use version from go directive if
// 'GOTOOLCHAIN' has been explicitly set
if (process.env[GOTOOLCHAIN_ENV_VAR] !== GOTOOLCHAIN_LOCAL_VAL) {
  // toolchain directive: https://go.dev/ref/mod#go-mod-file-toolchain
  const matchToolchain = contents.match(
    /^toolchain go(1\.\d+(?:\.\d+|rc\d+)?)/m
  );
  if (matchToolchain) {
    return matchToolchain[1];
  }
}

The backwards-compatibility branch only applies when GOTOOLCHAIN is explicitly set to local in the environment, and there is no GOTOOLCHAIN setting anywhere in this repo. Note this is a v6+ behaviour, so it would not have worked while the repo was on setup-go v5.

Sibling modules

collector/go.mod is the only go.mod any go-version-file in this repo points at, so it is the only toolchain pin that reaches a published artifact. The other seven are deliberately left alone:

• lambdacomponents, lambdalifecycle, processor/coldstartprocessor, processor/decoupleprocessor and receiver/telemetryapireceiver are replaced into the collector module and compiled into the same binary by the single go build in collector/Makefile, so the toolchain selected above already builds them. Their own go directives never reach setup-go.
• collector/internal/tools/go.mod is tooling and is not part of the shipped layer.
• go/sample-apps/function/go.mod is a sample app that no release workflow builds or publishes.
• The Java, Node.js, Python and Ruby layer releases do not invoke setup-go at all, so they are not exposed to this.

Happy to add the directive to the others for consistency if you would prefer it uniform.

Testing

Being straightforward about what I did and did not run. I could not compile the collector locally: collector/go.mod already requires go >= 1.26.1, which is newer than the Go on my machine, and that was equally true before this change. What I did verify:

• go mod edit -json parses the patched file, reporting Go: 1.26.1 and Toolchain: go1.26.7.
• Replaying the two regexes above from setup-go v7.0.0 against the patched file selects 1.26.7 rather than 1.26.1.

ci-collector.yml builds and tests the collector on every PR using the same go-version-file: collector/go.mod, so this PR's own checks should exercise the new toolchain end to end. Worth a look at the build log to confirm it reports go1.26.7.

[linux-foundation-easycla]

• ❌ - login: @arein / name: Derek Rein. The commit (021b88e) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

[thompson-tomo]

@arein I might be missing something but i am not following.

Bumping the go directive would also raise the minimum Go version required of importers of this module, which seemed like the wrong side effect for a build-time concern.

When would someone be importing the collector as a module? I can understand the other go-mod being imported when someone is building their own collector/layer.

The bigger question for me is renovate is detecting the go version in the go mod, what has stoped it from being auto updated