What is wrong. The shipped binary is built with cgo, and the only reason is a library webhooker never uses. gorm.io/driver/sqlite has a blank import of github.com/mattn/go-sqlite3, a cgo wrapper around SQLite's C source. webhooker opens every SQLite file with modernc.org/sqlite (pure Go) in internal/database/sqlite_open.go and hands the open connection to gorm (sqlite.Dialector{Conn: ...}), so mattn's driver is never opened. Its C SQLite is still compiled and linked, and the build pays for it: a C toolchain, a second static relink in the Dockerfile builder stage, and three build tags (netgo, osusergo, sqlite_omit_load_extension) that exist only to make that static glibc binary safe on Alpine. REPO_POLICIES.md's Go Dockerfile builds with CGO_ENABLED=0, and the owner's Go defaults name modernc.org/sqlite, pure Go, no cgo.
Change. Build the binary with CGO_ENABLED=0, in the Makefile's build target so local builds match the image. mattn's package then compiles to its pure Go stub, which registers a sqlite3 driver that only returns an error and that webhooker never opens. The static relink step and its three tags go: a Go binary without cgo is static by itself. The test stage keeps cgo, because Go's race detector needs it on Linux; its comment says that and nothing about mattn.
What it touches.Dockerfile (builder stage build and relink; the comments in the lint, test and builder stages that blame mattn), Makefile (build), internal/versionscript/version_script_test.go (it asserts the relink line), and the README's Docker, dependency and build sections (the sentences on cgo and mattn).
Definition of done. The image's binary is built with cgo off, as its embedded build settings show; the Dockerfile builds the binary once, with no static relink and none of the three tags; the image starts and passes its health check; no README or Dockerfile sentence says the binary needs cgo, and the README says in one line that mattn's stub is linked but never used. Dropping gorm itself is a separate question for the owner on #538 and is not part of this.
Builds after #536, which changes the Dockerfile and the README's Docker section.
Model: opus-5-5
**What is wrong.** The shipped binary is built with cgo, and the only reason is a library webhooker never uses. `gorm.io/driver/sqlite` has a blank import of `github.com/mattn/go-sqlite3`, a cgo wrapper around SQLite's C source. webhooker opens every SQLite file with `modernc.org/sqlite` (pure Go) in `internal/database/sqlite_open.go` and hands the open connection to gorm (`sqlite.Dialector{Conn: ...}`), so mattn's driver is never opened. Its C SQLite is still compiled and linked, and the build pays for it: a C toolchain, a second static relink in the `Dockerfile` builder stage, and three build tags (`netgo`, `osusergo`, `sqlite_omit_load_extension`) that exist only to make that static glibc binary safe on Alpine. `REPO_POLICIES.md`'s Go Dockerfile builds with `CGO_ENABLED=0`, and the owner's Go defaults name `modernc.org/sqlite`, pure Go, no cgo.
**Change.** Build the binary with `CGO_ENABLED=0`, in the Makefile's `build` target so local builds match the image. mattn's package then compiles to its pure Go stub, which registers a `sqlite3` driver that only returns an error and that webhooker never opens. The static relink step and its three tags go: a Go binary without cgo is static by itself. The test stage keeps cgo, because Go's race detector needs it on Linux; its comment says that and nothing about mattn.
**What it touches.** `Dockerfile` (builder stage build and relink; the comments in the lint, test and builder stages that blame mattn), `Makefile` (`build`), `internal/versionscript/version_script_test.go` (it asserts the relink line), and the README's Docker, dependency and build sections (the sentences on cgo and mattn).
**Definition of done.** The image's binary is built with cgo off, as its embedded build settings show; the Dockerfile builds the binary once, with no static relink and none of the three tags; the image starts and passes its health check; no README or Dockerfile sentence says the binary needs cgo, and the README says in one line that mattn's stub is linked but never used. Dropping gorm itself is a separate question for the owner on https://git.eeqj.de/sneak/webhooker/issues/538 and is not part of this.
Builds after https://git.eeqj.de/sneak/webhooker/pulls/536, which changes the Dockerfile and the README's Docker section.
Model: opus-5-5
clawbot
self-assigned this 2026-10-15 11:57:39 +02:00
Built in #550: make build, and so the image, now builds with cgo off, and the Dockerfile builds the binary once, with no static relink and none of its three tags.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/550: `make build`, and so the image, now builds with cgo off, and the Dockerfile builds the binary once, with no static relink and none of its three tags.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What is wrong. The shipped binary is built with cgo, and the only reason is a library webhooker never uses.
gorm.io/driver/sqlitehas a blank import ofgithub.com/mattn/go-sqlite3, a cgo wrapper around SQLite's C source. webhooker opens every SQLite file withmodernc.org/sqlite(pure Go) ininternal/database/sqlite_open.goand hands the open connection to gorm (sqlite.Dialector{Conn: ...}), so mattn's driver is never opened. Its C SQLite is still compiled and linked, and the build pays for it: a C toolchain, a second static relink in theDockerfilebuilder stage, and three build tags (netgo,osusergo,sqlite_omit_load_extension) that exist only to make that static glibc binary safe on Alpine.REPO_POLICIES.md's Go Dockerfile builds withCGO_ENABLED=0, and the owner's Go defaults namemodernc.org/sqlite, pure Go, no cgo.Change. Build the binary with
CGO_ENABLED=0, in the Makefile'sbuildtarget so local builds match the image. mattn's package then compiles to its pure Go stub, which registers asqlite3driver that only returns an error and that webhooker never opens. The static relink step and its three tags go: a Go binary without cgo is static by itself. The test stage keeps cgo, because Go's race detector needs it on Linux; its comment says that and nothing about mattn.What it touches.
Dockerfile(builder stage build and relink; the comments in the lint, test and builder stages that blame mattn),Makefile(build),internal/versionscript/version_script_test.go(it asserts the relink line), and the README's Docker, dependency and build sections (the sentences on cgo and mattn).Definition of done. The image's binary is built with cgo off, as its embedded build settings show; the Dockerfile builds the binary once, with no static relink and none of the three tags; the image starts and passes its health check; no README or Dockerfile sentence says the binary needs cgo, and the README says in one line that mattn's stub is linked but never used. Dropping gorm itself is a separate question for the owner on #538 and is not part of this.
Builds after #536, which changes the Dockerfile and the README's Docker section.
Model: opus-5-5
Built in #550:
make build, and so the image, now builds with cgo off, and the Dockerfile builds the binary once, with no static relink and none of its three tags.Model: opus-5-5