Skip to content

chore: bump osv-scanner to v2.4.0 and go to 1.26.4#618

Open
tolzhabayev wants to merge 7 commits into
mainfrom
chore/bump-osv-scanner-v2.4.0
Open

chore: bump osv-scanner to v2.4.0 and go to 1.26.4#618
tolzhabayev wants to merge 7 commits into
mainfrom
chore/bump-osv-scanner-v2.4.0

Conversation

@tolzhabayev

Copy link
Copy Markdown
Collaborator

Bumps github.com/google/osv-scanner/v2 from v2.3.8 to v2.4.0.

v2.4.0 requires Go >= 1.26.4, so I bumped the go directive and the Dockerfile builder image to 1.26.4 (the latest stable release — 1.27 is still an RC). The CI workflows read the version from go.mod via go-version-file, so they pick this up automatically.

Also dropped the runtime-spec v1.2.1 replace directive. It was there to keep containerd v1.7.x compilable, but v2.4.0 moves osv-scanner onto containerd v2, so the pin is no longer needed and the build is clean without it.

Build and the osv-scanner pass tests are green. The only failing tests are the pre-existing reactcompat integration tests, which fail identically on main (environment-dependent react-detect output).

osv-scanner v2.4.0 requires go >= 1.26.4, so bump the go directive and
the Dockerfile builder image to match (1.26.4 is the latest stable; 1.27
is still an RC). CI reads the version from go.mod via go-version-file, so
the workflows pick this up automatically.

Drop the runtime-spec v1.2.1 replace: it existed to keep containerd
v1.7.x compilable, and v2.4.0 moves osv-scanner onto containerd v2, so
that pin is no longer needed and the build is clean without it.
@tolzhabayev tolzhabayev self-assigned this Jun 19, 2026
@tolzhabayev tolzhabayev marked this pull request as ready for review June 19, 2026 11:19
@tolzhabayev tolzhabayev requested a review from a team as a code owner June 19, 2026 11:20
@grafana-catalog-project-bot grafana-catalog-project-bot Bot moved this from 📬 Triage to 🔬 In review in Grafana Catalog Team Jun 19, 2026
Switch the final stage from alpine:3.23 to golang:1.26.4-alpine3.24.
Bump the pinned nodejs to 24.16.0-r0, the version available in
alpine 3.24/main (the previous 24.14.1-r0 pin only exists in 3.23 and
would fail the apk add).
Comment thread Dockerfile Outdated
Comment thread Dockerfile
RUN mage -v build:ci

FROM alpine:3.23@sha256:5b10f432ef3da1b8d4c7eb6c487f2f5a8f096bc91145e68878dd4a5019afde11
FROM golang:1.26-alpine@sha256:3ad57304ad93bbec8548a0437ad9e06a455660655d9af011d58b993f6f615648

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

@academo switched to floating tag

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

it's still pinned to the hash so it makes no difference.

academo
academo previously approved these changes Jun 19, 2026
The floating golang:1.26-alpine base now resolves to alpine 3.24, which
ships Python 3.14. semgrep 1.84.1 imports pkg_resources, removed in
3.14, so it failed to run and the coderules analyzer produced no
findings (failing its tests). 1.167.0 supports Python 3.14 natively.
Temporary instrumentation to diagnose why the coderules tests see zero
semgrep findings on the CI runner but pass everywhere locally. Revert
once root cause is found.
Bumping semgrep to an OCaml-5 build (1.167.0) made semgrep-core crash in
the buildkit build sandbox on musl with "Failed to allocate signal stack
for domain 0", so the coderules analyzer got no findings and its tests
failed. Pin back to the OCaml-4 1.84.1 line, which runs in that sandbox,
and add setuptools<81 so pkg_resources is available under Python 3.14.

Reverts the temporary coderules debug logging.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🔬 In review

Development

Successfully merging this pull request may close these issues.

2 participants