Open coolaj86 opened 6 months ago
I experimented with tinygo
~yr ago, and ran into weird build issues. Didn't bother pursuing this in favor of building features, bug fixes and improving docs.
Most of the bloat in the published binaries comes from the SQL drivers, since the pre-built goose binary aims to support all of them.
However, you can reduce the resulting binary size by using the exclusive build tags:
https://pressly.github.io/goose/installation/#building-from-source (a bit out-of-date, will update)
go build \
-ldflags="-s -w" \
-tags='no_postgres no_sqlite3 no_clickhouse no_mssql no_mysql no_vertica no_ydb' \
-o goose ./cmd/goose
3.6M ./goose
# target only sqlite
go build \
-ldflags="-s -w" \
-tags='no_postgres no_clickhouse no_mssql no_mysql no_vertica no_ydb' \
-o goose ./cmd/goose
7.2M ./goose
go build \
-ldflags="-s -w" \
-tags='no_sqlite3 no_clickhouse no_mssql no_mysql no_vertica no_ydb' \
-o goose ./cmd/goose
10M ./goose
go build -o goose ./cmd/goose
41M ./goose
Fwiw I'd love to reduce the resulting binary size, which will inevitably grow over time as more drivers are added.
I acknowledge it's not great, but I also don't have a good answer for this at the moment.
Those file sizes are dang huge for something that just reads text files in lexicographical order, connects to a DB, and execs them.
Especially for a tool that is needed as part of ci/cd.
Would you consider building with
tinygo
?(it drops the advanced garbage collector for a much simpler one, but otherwise implements the same API)
Example: