Where it comes from. webhooker talks to SQLite through modernc.org/sqlite, which is pure Go: every database file is opened with it (internal/database/sqlite_open.go) and the open connection is handed to gorm. But gorm's SQLite adapter, gorm.io/driver/sqlite, also imports github.com/mattn/go-sqlite3, which wraps SQLite's C source and needs cgo. webhooker never uses that driver, yet its C SQLite is compiled into the binary.
What it costs. The image build needs a C compiler and a Debian Go image, builds the binary twice (the second time statically linked against glibc so it runs on Alpine), and carries three build tags whose only job is to make that static glibc binary safe. The shipped binary contains two SQLite engines, one of them unused.
Recommendation, being built. Build the binary with cgo off. mattn's package then compiles to a pure Go stub that is never called, the binary contains only the pure Go SQLite, and the second build and the three tags go. Your Go defaults and REPO_POLICIES.md already decide this, so it is filed and queued as #545. Tests keep cgo, because Go's race detector needs it on Linux.
Your choice: drop gorm as well? That would also take mattn out of go.mod, and your defaults say "not gorm". It touches 32 non-test files across internal/database, internal/delivery and internal/handlers: every query becomes plain database/sql with hand-written row scanning. The schema already comes from SQL migration files, not from gorm. Recommendation: not now. #545 removes cgo with a small change, and dropping gorm would collide with the six data-model changes you approved today. If you want it, I file it to build after those land.
Model: opus-5-5
**Where it comes from.** webhooker talks to SQLite through `modernc.org/sqlite`, which is pure Go: every database file is opened with it (`internal/database/sqlite_open.go`) and the open connection is handed to gorm. But gorm's SQLite adapter, `gorm.io/driver/sqlite`, also imports `github.com/mattn/go-sqlite3`, which wraps SQLite's C source and needs cgo. webhooker never uses that driver, yet its C SQLite is compiled into the binary.
**What it costs.** The image build needs a C compiler and a Debian Go image, builds the binary twice (the second time statically linked against glibc so it runs on Alpine), and carries three build tags whose only job is to make that static glibc binary safe. The shipped binary contains two SQLite engines, one of them unused.
**Recommendation, being built.** Build the binary with cgo off. mattn's package then compiles to a pure Go stub that is never called, the binary contains only the pure Go SQLite, and the second build and the three tags go. Your Go defaults and `REPO_POLICIES.md` already decide this, so it is filed and queued as https://git.eeqj.de/sneak/webhooker/issues/545. Tests keep cgo, because Go's race detector needs it on Linux.
**Your choice: drop gorm as well?** That would also take mattn out of `go.mod`, and your defaults say "not gorm". It touches 32 non-test files across `internal/database`, `internal/delivery` and `internal/handlers`: every query becomes plain `database/sql` with hand-written row scanning. The schema already comes from SQL migration files, not from gorm. Recommendation: not now. https://git.eeqj.de/sneak/webhooker/issues/545 removes cgo with a small change, and dropping gorm would collide with the six data-model changes you approved today. If you want it, I file it to build after those land.
Model: opus-5-5
clawbot
removed their assignment 2026-10-15 11:57:54 +02:00
sneak
was assigned by clawbot2026-10-15 11:57:54 +02:00
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.
Where it comes from. webhooker talks to SQLite through
modernc.org/sqlite, which is pure Go: every database file is opened with it (internal/database/sqlite_open.go) and the open connection is handed to gorm. But gorm's SQLite adapter,gorm.io/driver/sqlite, also importsgithub.com/mattn/go-sqlite3, which wraps SQLite's C source and needs cgo. webhooker never uses that driver, yet its C SQLite is compiled into the binary.What it costs. The image build needs a C compiler and a Debian Go image, builds the binary twice (the second time statically linked against glibc so it runs on Alpine), and carries three build tags whose only job is to make that static glibc binary safe. The shipped binary contains two SQLite engines, one of them unused.
Recommendation, being built. Build the binary with cgo off. mattn's package then compiles to a pure Go stub that is never called, the binary contains only the pure Go SQLite, and the second build and the three tags go. Your Go defaults and
REPO_POLICIES.mdalready decide this, so it is filed and queued as #545. Tests keep cgo, because Go's race detector needs it on Linux.Your choice: drop gorm as well? That would also take mattn out of
go.mod, and your defaults say "not gorm". It touches 32 non-test files acrossinternal/database,internal/deliveryandinternal/handlers: every query becomes plaindatabase/sqlwith hand-written row scanning. The schema already comes from SQL migration files, not from gorm. Recommendation: not now. #545 removes cgo with a small change, and dropping gorm would collide with the six data-model changes you approved today. If you want it, I file it to build after those land.Model: opus-5-5