Push a master-tagged image

[JaimeLennox]

Push a new docker image with tag "master" for every new build on the
master branch. This gives users wishing to run with the latest
development changes an easy way to stay up to date.

Note: when a tag is created, Travis sets the $TRAVIS_BRANCH envvar to
the tag, rather than the branch, hence why we only use this variable
now.

Closes: #139.

[aschmolck]

Good idea! But now just doing make w/o passing VERSION expliciltly will misbehave. One way to fix would be for the makefile to check if the variable is unset and blow up. But a sane default that only gets overriden when necessary might work better. I was going to suggest:

# top of Makefile
VERSION?=$$(cat version)

But maybe using the branch name is a better default:

VERSION?=$$(git rev-parse --abbrev-ref HEAD)

I can't remember why we introduced the version file, but it's also something that we probably could get rid off (in favor of just querying the tag).

Finally, maybe we should nuke the smarkets HQ images at last with the next "proper" release or do a final release.

I also think there is a bit of a support risk with making it too easy for people to be on bleeding edge, so it might be better to give it a less enticing name (like unstable or bleeding-edge).

[aschmolck]

Don't you want TRAVIS_TAG here somwhere? I don't get how we'd still get correctly v3.2.1 style tagged docker images with this (since what you docker push is always tagged as master, as far as I can tell).

[JaimeLennox]

According to the Travis docs (https://docs.travis-ci.com/user/environment-variables/#default-environment-variables):
TRAVIS_BRANCH: for builds triggered by a tag, this is the same as the name of the tag (TRAVIS_TAG).
So I think this should work as expected.

[JaimeLennox]

Yeah, I was thinking of getting rid of smarketshq images as well. We can nuke it after the next release, I guess.

I think this tag should be called master - its different enough from the standard docker conventions that I don't think anyone choosing this would find it unexpected, and it's much clearer what it represents like this. Maybe we should only update the latest tag on new versions and not on master builds instead? And/or we could mention this in the README.

I'll add the default VERSION as the branch, I guess that makes sense to do.

[JaimeLennox]

I added a stable tag, which corresponds to the latest versioned tag, and updated the README with a bit of info about this. What do you think?

[aschmolck]

I think :latest should be :stable (meaning we can probably drop :stable, although I'm not opposed to it either). If you docker run smarkets/marge-bot, you should get a release version, IMO.

[aschmolck]

I think the connotations of master differ by community; e.g. go's package mangement will install master, so that better be stable not bleeding edge. I'm fine w/ using it though, if it turns out to cause confusion to some users, we can change to unstable or whatever. I don't think :latest should equal :master though; I think :latest always ought to be the latest release version, if you want bleeding edge you should have to say so explicitly, rather than the other way around where you need to say you wan :stable.

[JaimeLennox]

Ok, I'm happy for it to behave that way too. I've left the stable tag in as it's more explicit.