Skip to content

chore: build the Go images on 1.27 so downstream modules can target it - #21

Merged
charankamarapu merged 2 commits into
mainfrom
chore-go-1.27
Aug 31, 2026
Merged

chore: build the Go images on 1.27 so downstream modules can target it#21
charankamarapu merged 2 commits into
mainfrom
chore-go-1.27

Conversation

@charankamarapu

Copy link
Copy Markdown
Contributor

What this does

Moves every Go-carrying CI image from Go 1.26 → 1.27, and bumps golangci-lint to a release actually built with Go 1.27.

Why

keploy OSS declares go 1.27.0 from v3.6.25 onward. Any repo bumping its go.keploy.io/server/v3 pin past v3.6.24 must declare go 1.27.0 too — there is no way around it:

$ go build ./...
go: go.keploy.io/server/v3@v3.6.27 requires go >= 1.27.0 (running go 1.26.0)

Every Go image here is still on 1.26, so those repos can't build or lint in CI. k8s-proxy already crossed this line (pins v3.6.25, runs golang:1.27); enterprise is blocked on it right nowenterprise#2469 has 5 red checks solely because of this, with go build, go vet and all 61 test packages passing locally.

The changes

Image Pin Before After
keploy-ci ARG GO_VERSION 1.26.0 1.27.0
keploy-ci-go-build FROM golang: 1.26-bookworm 1.27-bookworm
keploy-ci-golint FROM golang: 1.26-bookworm 1.27-bookworm
keploy-ci-golint ARG GOLANGCI_LINT_VERSION v2.9.0 v2.13.2

The other nine families (slim, java, python, node, playwright, timefreeze, awscli, azurecli, lighthouse) carry no Go and are untouched. Go 1.27.0 is currently the only 1.27 patch, so there's no version ambiguity.

⚠️ The golangci-lint bump is required, not cosmetic

The base-image bump alone would not have fixed lint. keploy-ci-golint installs a prebuilt binary via install.sh, so what matters is the Go version golangci-lint's own release workflow built with — not the Go in this image. golangci-lint refuses to run when its build Go is older than the module's target:

can't load config: the Go language version (go1.26) used to build golangci-lint
is lower than the targeted Go version (1.27.0)

(reproduced locally against the enterprise module)

Checking golangci-lint's release workflow per tag:

golangci-lint built with
v2.9.0 (current pin) Go 1.26
v2.13.0 Go 1.27.0 ✅ first release that works
v2.13.2 (chosen) Go 1.27.0 ✅ latest patch of that line

Consumer heads-up: that's a 2.9 → 2.13 jump, so govet/staticcheck rule sets have grown and repos may see new findings on existing code. Configs pinning an explicit linters.enable list (enterprise does: govet, staticcheck, errcheck, ineffassign, unused) won't pick up newly added linters, but the existing ones can report more.

After merge

publish.yml is tag-driven (type=semver,pattern=${tag-prefix}{{version}}), so cutting the next tag after v1.2.31 publishes the new round — go-build-*, golint-*, base, and the rest. Consumers then move their keploy-ci:*-1.2.26 references to it. enterprise#2469 is waiting on exactly that.

Testing

Not built locally — the images build in this repo's own CI. The Go-version reasoning above was verified directly: the requires go >= 1.27.0 failure, the golangci-lint refusal, and each release's build Go version were all checked against the real artifacts.

keploy OSS declares `go 1.27.0` from v3.6.25 onward, so any repo bumping
its go.keploy.io/server/v3 pin past v3.6.24 must declare `go 1.27.0` too
— there is no way around it:

    go: go.keploy.io/server/v3@v3.6.27 requires go >= 1.27.0 (running go 1.26.0)

Every Go-carrying image here is still on 1.26, so those repos cannot
build or lint in CI. k8s-proxy already crossed this line (it pins v3.6.25
and runs golang:1.27), enterprise is blocked on it right now.

Three pins move:
  keploy-ci            ARG GO_VERSION      1.26.0 -> 1.27.0
  keploy-ci-go-build   FROM golang:        1.26   -> 1.27-bookworm
  keploy-ci-golint     FROM golang:        1.26   -> 1.27-bookworm

The other nine families carry no Go and are untouched.

golangci-lint needs a fourth change, and the base-image bump alone would
NOT have fixed it. keploy-ci-golint installs a PREBUILT binary via
install.sh, so the Go version that matters is the one golangci-lint's own
release workflow built with, not the one in the image. golangci-lint
refuses to run when its build Go is older than the module's target:

    can't load config: the Go language version (go1.26) used to build
    golangci-lint is lower than the targeted Go version (1.27.0)

The pinned v2.9.0 is built with Go 1.26; v2.13.0 is the first release
built with Go 1.27.0. Pin v2.13.2, the latest patch of that line.

Note for consumers: that is a 2.9 -> 2.13 jump, so govet/staticcheck rule
sets have grown and repos may see new findings on existing code. Configs
that pin an explicit `linters.enable` list (enterprise does) will not pick
up newly added linters, but existing ones can report more.

Cut a tag after merging so publish.yml produces the new round; consumers
then move their keploy-ci:*-<version> references to it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Charan Kamarapu <charan@keploy.io>
Copilot AI lite review requested due to automatic review settings August 31, 2026 09:42

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

The first push failed to build keploy-ci-golint on both arches:

    err hash_sha256_verify checksum for
    '/tmp/.../golangci-lint-2.13.2-linux-amd64.tar.gz' did not verify 2277d43b...

The archive was fine — 2277d43b... is exactly the checksum golangci-lint
publishes for it. What failed is install.sh's lookup. From v2.13.0 each
release also ships an SBOM named "<tarball>.sbom.json", so the checksums
file holds two lines whose names both CONTAIN the tarball name, and
install.sh reads the expected hash with an unanchored grep:

    want=$(grep "${BASENAME}" "${checksums}" | tr '\t' ' ' | cut -d ' ' -f 1)

$want ends up holding both hashes, so the compare never matches (the
error prints "${want} vs $got", and the log showing a lone hash with no
"vs" is that multi-line $want). v2.9.0 predates the SBOM and has exactly
one matching line, which is why the old pin worked.

There is no version that avoids both problems: v2.13.0 is the first
release built with Go 1.27, and the SBOM starts in that same release, so
every version new enough to lint a `go 1.27.0` module trips the bug.

Install the archive directly instead, matching the checksum line on the
EXACT filename so the SBOM entry cannot collide. Verification is kept —
sha256sum -c against the published checksum, and a non-empty $want is
asserted so a lookup miss fails loudly rather than skipping the check.

Verified end to end on linux/amd64:
  golangci-lint has version 2.13.2 built with go1.27.0
and that binary lints the enterprise module (`go 1.27.0`) successfully,
which is the failure this whole change exists to fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Charan Kamarapu <charan@keploy.io>
@charankamarapu
charankamarapu merged commit 55498e6 into main Aug 31, 2026
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants