Update go to 1.26.7 for 19-1-stable

🤖 AI-authored change.

What does this MR do and why?

Raises GO_VERSION, GO_FIPS_VERSION and GO_FIPS_TAG from 1.25.14 to 1.26.7 on 19-1-stable, and the matching ARG defaults in the three gitlab-go Dockerfiles.

gitlab-elasticsearch-indexer v5.14.14 declares go 1.26.0 in its go.mod, and gitlab-elasticsearch-indexer/Dockerfile sets ENV GOTOOLCHAIN=local, so a 1.25 toolchain refuses the build instead of fetching a newer one:

go: go.mod requires go >= 1.26.0 (running go 1.25.14; GOTOOLCHAIN=local)

19.1 has already taken that indexer version in the Rails monolith (gitlab!255991), while this branch still pins v5.14.13. The next Update VERSION files sync moves the pin and the indexer image build fails, so this is a latent break rather than a new capability.

19-2-stable, 19-3-stable and 19-4-stable already carry 1.26.7 (CNG!3070). This aligns 19-1-stable with them and keeps Go at its most recent supported patch level.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch. master is on 1.26.7; the same version shipped to 19-2-stable.
  • The original MR has been deployed to GitLab.com (not applicable for documentation or spec changes). 1.26.7 has been on master and 19-2-stable since 2026-09-04.
  • This MR has a severity label assigned (if applicable). Not applicable — no shipped behaviour is broken today.
Build verification

Five local docker build runs against this branch's Dockerfiles, GOTOOLCHAIN=local as shipped:

# build expected exit
A gitlab-go at GO_VERSION=1.26.7 pass 0
B gitlab-go at 1.25.14 (control) pass 0
C indexer v5.14.14 on the 1.26.7 image pass 0
D indexer v5.14.14 on the 1.25.14 image fail 1
E indexer v5.14.13 on the 1.26.7 image pass 0

D is the failure this MR removes, reproducing the message above verbatim. E shows the currently-pinned indexer still builds on the newer toolchain, so the pin need not move in the same change. C's image reports go version go1.26.7 linux/amd64. The FIPS tag go1.26.7-1-openssl-fips resolves in golang-fips/go.

19-0-stable and 18-11-stable stay on 1.25.11: their monolith branches still pin indexer v5.14.7, so neither is broken by this class of failure yet.

What I did not verify

The FIPS and UBI images — building those needs the manual fips_pipeline bridge job on this MR's pipeline, per the repo's AGENTS.md. GO_FIPS_TAG was checked only for existence upstream, not by building against it. No downstream chart or Helm deployment was exercised.


🤖 Automated change — mention me to get a response. Feedback welcome. Ask to speak to John directly anytime.

Edited by John Mason

Merge request reports

Loading
Loading