[DO NOT MERGE]: Update Go version to 1.26

[probelabs]

Problem / Task

Update Go version to 1.26 in tyk-pump as requested in TT-17721.

Requested by: U03DRQLT012
Slack thread: https://tyktech.slack.com/archives/D0A8NFK7XL2/p1785316401755029

Changes

• Updated go.mod to use Go 1.26.0
• Updated Dockerfile to use golang:1.26
• Updated .github/workflows/ci-test.yml to use Go 1.26
• Updated .github/workflows/linter.yaml to use Go 1.26
• Updated .github/workflows/release.yml to use 1.26-bookworm

Testing

• Verified build passes locally with go build -v ./...

[probelabs]

This PR updates the Go version from 1.25 to 1.26 across the project's configuration, affecting the build, testing, and release pipelines.

Files Changed Analysis

The update is consistently applied across 5 configuration files:

• go.mod: Sets the Go module version to 1.26.0.
• Dockerfile: Updates the base builder image from a SHA-pinned golang:1.25 to a floating golang:1.26 tag.
• .github/workflows/ci-test.yml: Configures the CI test matrix to use Go 1.26.
• .github/workflows/linter.yaml: Configures the linter job to use Go 1.26 and updates the golangci-lint-action from v2.5.0 to v2.12.2.
• .github/workflows/release.yml: Updates the golang-cross build image to 1.26-bookworm for the release process.

The changes are primarily version string replacements, with a notable removal of the SHA256 digest from the Dockerfile's base image.

Architecture & Impact Assessment

• What this PR accomplishes: It standardizes the project's toolchain on Go 1.26, ensuring the application is built and tested with a more recent version of the Go compiler.

• Key technical changes introduced: The core change is the version bump of the Go toolchain. This impacts the entire CI/CD pipeline and the resulting compiled artifacts. Notably, the base Docker image is no longer pinned to a specific digest, which could affect build reproducibility.

• Affected system components:

  • CI/CD Pipeline: All GitHub Actions workflows (build, lint, release) will now execute using a Go 1.26 environment.
  • Build Artifacts: The compiled binaries and Docker images will be built using the Go 1.26 compiler.
  • Development Environment: Developers will need to update their local Go version to 1.26 to maintain consistency.

graph TD
    subgraph "Configuration Files"
        A[go.mod]
        B[Dockerfile]
        C[GitHub Workflows]
    end

    subgraph "Build & Release Pipeline"
        D(Go 1.26 Toolchain)
        E{Build Process}
    end

    subgraph "Output Artifacts"
        F[Compiled Binaries]
        G[Docker Image]
    end

    A --> D
    B --> D
    C --> D
    D --> E
    E --> F
    E --> G

Loading

Scope Discovery & Context Expansion

• The scope of this change is confined to the project's build and development toolchain. It does not alter any application source code, minimizing the risk of functional regressions.
• The primary risk is the potential for subtle build failures or behavioral changes introduced by the new Go version. However, Go's backward compatibility promise makes this a low risk.
• The removal of the SHA256 pin from the Dockerfile base image is a potential concern for build reproducibility and security. The previous version was pinned, and this change reverts to a floating tag.
• A successful run of the full CI pipeline on this branch will be the main validation for this change.

Metadata

• Review Effort: 1 / 5
• Primary Label: chore

---

Powered by Visor from Probelabs

Last updated: 2026-07-29T11:37:59.400Z | Triggered by: pr_updated | Commit: cae3a06

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	Dockerfile:1	The Docker base image `golang:1.26` uses a floating tag. The previous image was pinned to a specific digest (`@sha256:...`), which is a security best practice to ensure reproducible and verifiable builds. Using a floating tag can introduce unexpected changes or vulnerabilities if the underlying image is updated. 💡 Suggestion Pin the `golang:1.26` base image to its specific SHA256 digest to ensure build immutability. You can find the digest by running `docker pull golang:1.26` and then `docker inspect golang:1.26` or `docker images --digests`. The line should be changed to something like `FROM golang:1.26@sha256:<digest-hash> as builder`.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	Dockerfile:2	The base Docker image `golang:1.26` uses a floating tag instead of a specific digest. This can lead to non-reproducible builds and may negatively impact build performance by bypassing caches if the upstream image is updated. The previous version was pinned to a specific digest (`@sha256:...`). 💡 Suggestion To ensure reproducible builds and optimal caching, pin the base image to a specific SHA256 digest. You can find the digest for the `golang:1.26` image from Docker Hub or by running `docker pull golang:1.26` and then `docker inspect golang:1.26` to get the `RepoDigests`.

Security Issues (1)

Severity	Location	Issue
🟡 Warning	Dockerfile:1	The Docker base image `golang:1.26` uses a floating tag. The previous image was pinned to a specific digest (`@sha256:...`), which is a security best practice to ensure reproducible and verifiable builds. Using a floating tag can introduce unexpected changes or vulnerabilities if the underlying image is updated. 💡 Suggestion Pin the `golang:1.26` base image to its specific SHA256 digest to ensure build immutability. You can find the digest by running `docker pull golang:1.26` and then `docker inspect golang:1.26` or `docker images --digests`. The line should be changed to something like `FROM golang:1.26@sha256:<digest-hash> as builder`.

\n\n \n\n

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	Dockerfile:2	The base Docker image `golang:1.26` uses a floating tag instead of a specific digest. This can lead to non-reproducible builds and may negatively impact build performance by bypassing caches if the upstream image is updated. The previous version was pinned to a specific digest (`@sha256:...`). 💡 Suggestion To ensure reproducible builds and optimal caching, pin the base image to a specific SHA256 digest. You can find the digest for the `golang:1.26` image from Docker Hub or by running `docker pull golang:1.26` and then `docker inspect golang:1.26` to get the `RepoDigests`.

\n\n ### Quality Issues (2)

Severity	Location	Issue
🟠 Error	.github/workflows/linter.yaml:108	The specified `golangci-lint` version `v2.12.2` appears to be invalid. Official `golangci-lint` versions follow a `v1.x.y` format. This incorrect version string will likely cause the linting workflow to fail. 💡 Suggestion Update the version to a valid `golangci-lint` release that supports Go 1.26. Please check the official `golangci-lint` releases and select a recent, compatible version.
🟠 Error	Dockerfile:1	The base image `golang:1.26` is not pinned to a specific digest (SHA256). The previous Dockerfile version pinned the base image, which is a security best practice for reproducible builds. Removing the digest pin introduces a risk, as the `golang:1.26` tag can be updated to point to a different, potentially malicious or broken, image. 💡 Suggestion To ensure deterministic and secure builds, pin the `golang:1.26` image to its content digest. First, pull the desired image (e.g., `docker pull golang:1.26.0-bookworm`), then find its digest with `docker images --digests golang`. Finally, update the Dockerfile to use the full digest, for example: `FROM golang:1.26.0-bookworm@sha256:<image-digest-hash>`.

---

Powered by Visor from Probelabs

Last updated: 2026-07-29T11:37:55.578Z | Triggered by: pr_updated | Commit: cae3a06

💡 TIP: You can chat with Visor using /visor ask <your question>

[github-actions]

🚨 Jira Linter Failed

Commit: cae3a06
Failed at: 2026-07-29 11:37:08 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to get Jira issue: Jira issue GO-1 not found (HTTP 404). The issue may exist but the API token may lack permission to access it. Verify that the token owner has access to the project and that JL_JIRA_BASEURL (https://api.atlassian.com/ex/jira/c25a3295-62f6-4d5a-8ddd-58122b144a37) is correct

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud