Build binaries in a docker container

[docker-archive]

Build binaries in a docker container

[justincormack]

I did make a container for build (non cross) and happy to contribute one as an example. Apart from the cross build issue, it is a bit annoying to use as you don't vendor your dependencies into the repo which means the Dockerfile looks like:

...
COPY . ./
RUN govendor sync
RUN make

Which makes it painfully slow to use for development as you have to re-sync each time you edit the source. I am currently vendoring infrakit and its dependencies so it is more usable for building in a container.

[wfarner]

it is a bit annoying to use as you don't vendor your dependencies into the repo

We've gone back and forth on this...i really like the idea of not checking in vendored sources, but it's starting to look impractical.

[thaJeztah]

SwarmKit recently switched to https://github.com/LK4D4/vndr you could check with them how that worked out so far

[wfarner]

Relevant: #189

[chungers]

I think I have a solution for the build in container / vendor / pain in the sync/ issue.

Basically I’ve separated out the code compilation and vendor sync into two separate steps. The vendor sync step is done in a container named by the hash of the vendor/vendor.json.

The compilation of infrakit code is in a separate container but uses the first container as the data volume (via the —volumes-from option in docker run). So the compiler sees the vendored code, and there's no need to do any more vendor sync unless the vendor/vendor.json file is updated -- at which time a new hash will produce a new data container / data volume. This will be reused across multiple compiles as long as the the hash doesn't change.

See #241