Adding a base Dockerfile

[Dynom]

Status

Ready for review.

• [ ] Collecting feedback
• [x] Creating a first workable version
• [x] Update CI config to use Docker containers for building
• [ ] Switch to auto-build Docker images on Docker Hub
• [ ] Updating documentation
• [ ] Create facade release instructions
• ~[ ] Added Delve and document remote debug instructions~ (Installing and setting up Delve is pretty easy, if it's an often enough use-case we can add it, for now I'd like real-world usage feedback if it's really needed).
• [x] Update this PR until it's ready enough for review
• [ ] Use go generate for version.go?

Findings

Building on CI takes a long time

Currently we build the entire base image on each CI build, this takes a long time. An obvious fix would be to cache the images. To do this we need to tag the images with the combinations we want to test for. So we then need to come up with a convention for tags. (e.g.: h2non/bimg:vips-8.7.2-go-1.11.4) but that can become ugly rather fast (do we include the ubuntu, or other package versions as well?).

Another advantage is that we can re-use 'm for Imaginary as well.

Considerations

Include bimg (source) or not

Currently I include the bimg source and even have a compile step in the Dockerfile. The rationale behind the compile step is that if it doesn't compile, the image should be considered invalid.

However, since bimg is a library and if the typical use-case is hacking on bimg, it makes little sense to include the source. I suspect that the typical use-case would then be to map a local folder into the container and use the local code instead. This still saves the headache of setting up the correct libvips version and it's dynamic dependencies.

New releases of bimg and updating the version

bimg exposes bimg.Version = 1.0.18. There isn't an automated way this is updated with a release. We could automate this proces with a go generate and write a new version.go for the latest tag. The file is nice and simple, this should be fairly trivial but does change a few things.

E.g.:

//go:generate sed -e "s/Version = \".*\"$/Version = \"${VERSION}\"/" version.go
package bimg

// Version represents the current package semantic version.
const Version = "dev"

and:

$ VERSION=1.2.3 go generate

produces:

//go:generate sed -e "s/Version = \".*\"$/Version = \"${VERSION}\"/" version.go
package bimg

// Version represents the current package semantic version.
const Version = "1.2.3"

However, sed isn't the most portable tool and differs on macOS/linux. Perhaps we should use a go run variant instead.

Typical use case

Verifying correctness with a specific set of version numbers

$ vim Dockerfile
$ docker build -t myLabel:latest \
  --build-arg LIBVIPS_VERSION=1.2.3 \
  --build-arg GO_VERSION=1.11.4 \
  .
...
Successfully built 76951297ff85
Successfully tagged myLabel:latest

echo "go test -test.race ./..." | docker run --rm -i -v "/local/path/to/bimg:/go/src/github/h2non/bimg" myLabel:latest

Hacking on bimg

Creating a build environment with specific versions:

$ docker build -t myLabel:latest \
  --build-arg LIBVIPS_VERSION=1.2.3 \
  --build-arg GO_VERSION=1.11.4 \
  .
...
Successfully built 76951297ff85
Successfully tagged myLabel:latest

$ docker run --rm -it -v "local/path/to/bimg:/go/src/github/h2non/bimg" myLabel:latest
root@d5f8c55eaec3:/go/src/github.com/h2non/bimg# go version
go version go1.11.4 linux/amd64

Imaginary

For Imaginary, see PR: https://github.com/h2non/imaginary/pull/229

Details

Quality Assurance

I picked Gometalinter. It typically plays well and contains most commonly used analysers. Just one package to rule 'm all. I've added a config file that works well for bimg, we can tune it as far as we want to take it. Personally I have some things I'd like to enable, but that won't solve any of the open issues and instead creates more work ;-)

Labels

The Dockerfile labels is the "new" way of dealing with metadata. I stuck to the http://label-schema.org/ standard for a few of the properties.

Assuming a --build-arg BIMG_VERSION=foobar during build, then a docker inspect h2non/bimg:build | jq '.[0].Config.Labels' produces:

{
  "go.version": "1.11.4",
  "libvips.version": "8.7.2",
  "maintainer": "[email protected]",
  "org.label-schema.description": "Small Go package for fast high-level image processing powered by libvips C library",
  "org.label-schema.schema-version": "1.0",
  "org.label-schema.url": "https://github.com/h2non/bimg",
  "org.label-schema.vcs-url": "https://github.com/h2non/bimg",
  "org.label-schema.version": "foobar"
}

[Dynom]

Addresses https://github.com/h2non/bimg/issues/272

[Dynom]

The build currently breaks because of unrelated (breaks on master as well) failing tests.

The main problems I currently see is that building takes a bit longer. I'm not sure if that's a real issue though, since it's on Travis and not locally. Speeding things up significantly also takes quite the endeavour as it requires a smart caching strategy. There are a myriad of ways to tackle this, perhaps something for a different issue.