Files
s3-csi/cmd/s3-mount/Dockerfile.dev
T
e8b89e78c3 chore: no seaweed, no weed — it is s3 (#4)
* fix(docker): clone the fork that exists, at a commit that exists

The s3-mount image has never built. A global rename turned the upstream
seaweedfs reference into `github.com/s3/s3`, which is not a repository, so the
build died on `git clone ... exit code 128` before compiling anything.

Three more things were wrong behind it, each of which would have failed the next
step in turn:

  clone   github.com/s3/s3        -> github.com/hanzoai/s3
  path    /go/src/github.com/s3/s3 -> /go/src/github.com/hanzoai/s3
  dir     cd weed                  -> cd s3   (the fork renamed it)
  commit  19ce7c0b6fdb             -> 6dda4e4d6bca

That commit is the real one. 19ce7c0b6fdb is an UPSTREAM seaweedfs hash and does
not exist in our fork — the API 422s on it — so the checkout could never have
succeeded even with the URL fixed. The ARG stays so a build can still pin.

SEAWEEDFS_COMMIT is renamed S3_COMMIT while we are here; nothing consumed it yet.

* chore: no seaweed, no weed — it is s3

369 occurrences across 33 files, plus nine files whose names carried it. All of
it gone: manifests, helm chart, nomad jobs, workflows, docs and code.

Two of these were not cosmetic.

The driver spawned a binary called "weed":

    DefaultWeedBinary = "weed"

Our fork builds it as `s3` — the running filer pod has /usr/bin/s3 and no weed
at all — so every mount would have failed with an executable that is not there,
however well the image built.

And the crash-recovery integration test killed processes matching `pgrep -x
weed`. Nothing is named that any more, so it would have found no pids, killed
nothing, and passed while testing exactly nothing. It now matches `s3`. The test
already had a guard that fails when there is nothing to kill, which is the only
reason this would have been noticed at all.

The rest follows the same rename the Dockerfile got: SEAWEEDFS_COMMIT is
S3_COMMIT, and the release/sync workflows that patch that ARG were updated with
it or they would silently stop pinning anything.

No upstream import paths were touched — go.mod depends on github.com/hanzoai/s3,
not on anything upstream, so nothing here was load-bearing for the build.
Verified: go build clean, all three test packages pass.

---------

Co-authored-by: hanzo-dev <[email protected]>

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-27 18:26:50 -07:00

30 lines
777 B
Docker

# S3_COMMIT should match the commit in go.mod for reproducibility
# Update via: docker build --build-arg S3_COMMIT=<hash> ...
ARG S3_COMMIT=19ce7c0b6fdb
FROM golang:1.25-alpine AS builder
RUN apk add git g++
# Build s3 binary from a specific commit for reproducibility
ARG S3_COMMIT
RUN git clone https://github.com/s3/s3 /go/src/github.com/s3/s3 \
&& cd /go/src/github.com/s3/s3 \
&& git checkout ${S3_COMMIT} \
&& cd s3 \
&& go install
# Build s3-mount from current context
WORKDIR /go/src/github.com/s3/s3-csi-driver
COPY . .
RUN go build -ldflags="-s -w" -o /s3-mount ./cmd/s3-mount/main.go
FROM alpine AS final
RUN apk add fuse
COPY --from=builder /go/bin/s3 /usr/bin/
COPY --from=builder /s3-mount /
RUN chmod +x /s3-mount
ENTRYPOINT ["/s3-mount"]