Post

Did a bit of hacking this weekend and cooked up "gocachez", a GOCACHEPROG which transparently compresses the Go build cache to save disk space at rest at the cost of CPU, with fairly good results. Building and testing TS would normally eat up roughly 4GB, but with gocachez it's only about 400MB.

Jake Bailey

@jakebailey.dev

I often work in multiple worktrees at a time, and with many builds and lint runs, I would often see GOCACHE at 200GB+. This saves about 10x. It's still a WIP, but you can try it with: $ go install github.com/jakebailey/gocachez@latest $ go env -w GOCACHEPROG=gocachez $ go env -u GOCACHEPROG # undo

github.comGitHub - jakebailey/gocachez: A GOCACHEPROG with zstd compression and auto cleanupA GOCACHEPROG with zstd compression and auto cleanup - jakebailey/gocachez

22/6/26, 8:31 pm0 reposts10 likes

Thomas Verdier

@buildwiththomas.bsky.social

24 June

Multiple worktrees plus concurrent builds is exactly where tooling friction starts to show. I am building a small CLI workflow now and keep coming back to cleanup, status, and defaults. What part breaks down first for you?