* dockerfiles: Drop duplicate mkdir
The mkdir gets executed if "Building from local dev copy", whereas if built from
upstream git, go get will take care of it.
* dockerfiles: Drop extra community repo
No longer needed with current edge or stable tags of alpine linux.
* dockerfiles: Drop gcc as an explicit dep; go pulls it
Current edge and 3.5 declare gcc as a dep for go.
* dockerfiles: Install glide from package repo
Both edge and 3.5 provide a packaged glide. By using the provided package,
we reduce the build time a little.
* dockerfiles: Set GLIDE_HOME to prevent glide to pollute /root
glide promptly ignores HOME (it checks /etc/passwd), but honours GLIDE_HOME.
So, by pointing GLIDE_HOME to a ephemeral dir, ~/.glide will be created there
instead of /root/.glide, simplifying the cleanup process.
* dockerfiles: Use --purge to ensure clean package uninstalls
This way, /usr/lib/go gets purged, and we don't have to remove it manually.
* dockerfiles: Move netboot tree instead of copying it
Less space used and slightly faster build.
* dockerfiles: Simplify build steps
go build will honour GOBIN and leave the executable there.
* dockerfiles: Move the installation of packages to the top
* dockerfiles: Upgrade first, then install new stuff
* dockerfiles: Tie build deps with a virtual package for easier removal
By deleting the virtual .build-deps package, one ensures the
no-package-left-behind policy :-)
* dockerfiles: Split package list in multiple lines
It's a good practice for enhancing the readability of pull requests,
since addition or removal of packages from the list will result in single line
changes.
* dockerfiles: Drop changing dir to /
No need to change directory in order do the cleanup.
* dockerfiles: Test the existence of the go package, instead of .git
This way we can add .git to .dockerignore, thus preventing copying it over when
building the image.
* dockerfiles: Add .dockerfile files to minimize the files that are copied over
* dockerfiles: Place build logic in the Dockerfile
Makes it easier to understand the build process if the whole sequence is stored
in a single place.
OTOH, editing the shell script inside the Dockerfile is a bit harder.
* dockerfiles: Create a sandbox where to put all transient files
* dockerfiles: Set GLIDE_HOME to the sandbox
* dockerfiles: Set GOPATH to a dir under the sandbox
* dockerfiles: Simplify cleanup
* dockerfiles: Rename 'stuff' to 'context', to use Dockerfile lore
* dockerfiles: Install entrypoint onto /usr/local/bin
This is the default location for locally managed binaries, and as such, PATH
includes it. This way, it is easier to run it interactively.
* dockerfiles: Extract sandbox and context paths into variables
* dockerfiles: Move vars up to help define other vars before they are used
* dockerfiles: Add the required vars to eliminate duplicated paths
* dockerfiles: Replace hardcoded paths with references to vars
* dockerfiles: Fix wording for clarity
* dockerfiles: Add emtpy line to improve readability
* dockerfiles: Tell the go linker to strip debugging symbols
This produces a sensibly smaller binary.
* dockerfiles: Drop the --rm to docker build, as it is the default behaviour
* dockerfiles: Use long flags for readability
* dockerfiles: Base image onto alpine:3.5
Now that 3.5 has been released, we can use it instead of edge, since it
provides go 1.7.3. We get a more stable environment, plus a smaller image.
The way docker hub and quay.io work, you can't easily pass a custom
context to a Dockerfile. So, effectively, if you want multiple dockerfiles
per repository, you need to re-check out the whole repository by hand,
without help from the environment.
This sucks a little bit because it doesn't guarantee that the build happens
at the trigger revision ID, but for my purposes of "just have a recent build up",
it's sufficient.
