Travis tags the repo with a release_??? tag

[fawkesley]

On a successful test run, Travis will now tag the commit with
release_<travis build number>

This uses an encrypted environment variable GH_TOKEN which is a
personal access token with permission to write to the repo.

[robyoung]

Will this commit as you? We have a couple of bot accounts created that it might make more sense to use. Or maybe create a new one ourselves.

Would it make sense to merge into a release branch and then tag from there? The only reason I say this is with the approach in this pull request the jenkins auto deploy job can only watch on master. This will result in it deploying before the tests have run.

[fawkesley]

1. In the current approach is doesn't make a commit at - it just adds a tag to an existing commit - so it won't commit as me. However it does make sense for the token to be owned by a shared account rather than by mine - can you point me to the credentials @robyoung ?
2. Ahh cunning, yes we do need another ref for the deploy job to use. It feels better to me if we could avoid having another merge commit (it's sort of polluting/faking the history on that branch) - maybe release should be another tag, so we just push release_123 and release each time? We'd have to force push release but as long as Jenkins didn't have a wobbly about it that might be a cleaner solution?

[fawkesley]

I've implemented these changes:

1. As well as adding the release_??? tag, add release and force push it.
2. Change the token to one belonging to @gds-pp-ci

[fawkesley]

Going to implement some improvements suggested by @nickgravgaard

[fawkesley]

Interesting, now we see in action it's clear that the scripts runs after every job in the build matrix - not after they have all finished. The feature request for this is tracked here: travis-ci/travis-ci#929

[fawkesley]

I'm pretty confident we can find a clean workaround, see http://docs.travis-ci.com/user/build-configuration/#Build-Lifecycle