Update go to 1.26.7 for 19-1-stable
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.
masteris on1.26.7; the same version shipped to19-2-stable. - The original MR has been deployed to GitLab.com (not applicable for documentation or spec changes).
1.26.7has been onmasterand19-2-stablesince 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.