Closed sgoings closed 8 years ago
So for 2, I was playing around with the idea of doing the build step inside of a Docker container instead of on the local system. My intent was also to do the same for the test
target. The reasoning behind this is that I feel like we're better off building in the target environment. (And this is even more so for tests).
The easiest way to do those seems to be to start with a common compiler container, bind-mount the local FS, and then run the make target. That's what my example Makefile does. That said, easiest may not be best. So I'm definitely open to alternatives.
Oh, and you brought up something that @mboersma also mentioned: It would probably be a good idea to define a subset of make targets that we will treat as required so that we can build additional cross-repo tooling. I can think of a few:
Maybe test
should be broken out into unit and functional?
The easiest way to do those seems to be to start with a common compiler container, bind-mount the local FS, and then run the make target. That's what my example Makefile does.
This is what we used to do by doing a go build
in a container then doing a docker cp
to grab the binary. We eventually swapped that out for using Go's cross-compiling feature, but I can see the win here.
Maybe test should be broken out into unit and functional?
That would make sense. Functional tests in deis/deis run a mock production workflow for the container using Docker, which we wouldn't be able to do inside a go:1.5 container.
Yeah, we could build our own container images for that, too.
Here's an example with a Makefile that still does local builds. https://github.com/technosophos/etcd
https://github.com/technosophos/prototype-repo/blob/master/Makefile
make
(with no arguments) would build the project