Rework build process to avoid repo bloat?

We may need to change the build process, at least as it concerns the built in assets (i.e. the GUI). Currently it works like this:

  • We have GUI stuff in the gui/ folder.
  • When that changes, or soon thereafter, it all gets compressed into lib/auto/gui.files.go.
  • This file is included when we build, and all the GUI assets are available compiled into the binary.

That’s fine and it’s worked for us for a long time. There’s a significant downside with that auto generated file though, and that is that it’s getting fairly large, almost 2 MB at this point. It being large isn’t a problem in itself. However it means that we add a 2 MB delta to the git repository on each GUI change, regardless of how small it is. This bloats our git repository quite fast.

There main reason we have this file available and checked into the repo is that a go get on the repo can now create a correct binary.

We could ignore that and simply recreate it on each build though, perhaps with some suitable caching to keep the rebuild time down when developing. Doing that would mean no longer being “go-gettable”, which in a way also frees us up to reorganize the repository to be independent of the user’s GOPATH and so on. It also means we’re a little less of a standard Go project.

Thoughts?

Can’t we just use the generate directive for that?

Certainly, but that’s still something that needs to be run manually - go build and go install doesn’t run go generate on it’s own.

I hacked an example in build: Generate gui.files.go on the fly, remove from repo by calmh · Pull Request #2898 · syncthing/syncthing · GitHub - it rebuilds the assets if they are missing or too old. This probably works fine, and frankly I’m not too worried about breaking go get. I don’t want unversioned binaries floating around anyway. :slight_smile:

I merged this this morning.