Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Dockerfile
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM golang:1.11.10-alpine as builder
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/go:1.11.10-dev as builder

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

The new cgr.dev/spotdraft.com/go:1.11.10-dev image runs as non-root (UID 65532) by default, so the apk update && apk add ... step fails, which blocks the later addgroup/adduser and go build -o /grpcui steps — should we add USER root before this setup and switch back afterward, or use an image whose default user is root?

Severity web_search

Want Baz to fix this for you? Activate Fixer

Fix in Cursor

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In Dockerfile around
lines 1-4 (builder stage), the base image was changed to
`cgr.dev/spotdraft.com/go:1.11.10-dev` whose default user is nonroot (UID 65532), but
the Dockerfile runs `apk update && apk add ...` and `addgroup`/`adduser` before any
`USER root`, so package installation fails and the later steps (creating users/groups,
copying /etc/ssl/certs/ca-certificates.crt and /etc/passwd into the scratch stage, and
`go build -o /grpcui`) never run. Add `USER root` immediately before the first `apk`
command, then switch back to the nonroot user after setup is complete (before `go build`
and any runtime setup), ensuring the scratch-copy steps still occur correctly.
Alternatively, if you prefer not to add user switching, replace the base image with one
whose default user is root.

MAINTAINER FullStory Engineering

# currently, a module build requires gcc (so Go tool can build
Expand Down