Makefile ideas for improvement

[sgoings]

https://github.com/technosophos/prototype-repo/blob/master/Makefile

1. make (with no arguments) would build the project
2. what's the difference between docker-compile and build?
   • Which one is more common?
   • How do both fit in with the whole lifecycle of targets (do any of the kube make targets rely on them)?
3. Maybe we could standardize these make targets ... i.e. pull in some shared makefile that defines this common behavior so that we don't have to maintain all these targets in every repo.

[technosophos]

1. Yeah, that is a good idea
2. docker-compile executes inside of a docker container, and will build for that environment. I'll explain below.
3. Suggestions on how to pull in the shared Makefile across repos without introducing stuff like submodules and subtrees? Gabe had suggested the alternate path: we build a tool that uses this repo to scaffold out new repos.

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:

• build
• deploy
• test

Maybe test should be broken out into unit and functional?

[bacongobbler]

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.

[technosophos]

Yeah, we could build our own container images for that, too.

[technosophos]

Here's an example with a Makefile that still does local builds. https://github.com/technosophos/etcd