Automated Travis/Github releases

[emcniece]

What?

This pull request enables automated Travis/Github pre-releases for master branch.

The following configuration proposal deploys master branch changes to a Github pre-release tagged as master-auto. This master-auto tag is reused for each future deploy, preventing tag buildup. Releases are overwritten, preventing release buildup.

Why?

A quick look through the project issues reveals a few tickets that could be assisted or avoided with more frequent releases:

• https://github.com/sourcegraph/checkup/issues/29
• https://github.com/sourcegraph/checkup/issues/37
• https://github.com/sourcegraph/checkup/issues/45
• https://github.com/sourcegraph/checkup/issues/52
• https://github.com/sourcegraph/checkup/issues/67
• https://github.com/sourcegraph/checkup/issues/84

Travis CI is capable of deploying anywhere, but since Github releases are already in use it makes sense to keep these artifacts in the same spot.

How?

Releases can be automated by extending the .travis.yml file. This pull request includes a few files:

• .travis.yml: Implements auto pre-release on master branch changes
• PLATFORMS: List of [OS]_[ARCH] used to create binaries
• README.md: Updated docs
• build-cross.sh: A cross-compiler assistant script, used manually and in Travis CI

The .travis.yml config contains some notable features:

• if: NOT tag = master-auto: Don't need to re-run test & deploy on master-auto tag updates, since they've already been done on the origin branch of master
• build-cross.sh is run with a max of 15 processes to enable simultaneous cross-platform compilation 🚄
• skip_cleanup: true: needed to ensure builds/* binaries can be uploaded as part of the release target_commitish: $TRAVIS_COMMIT: needed to ensure Travis releases with the right commit ID, otherwise releases are made titled "untagged-xxxxx"

Example

This proposal was tested on a fork. The output can be previewed at:

• Repo: https://github.com/emcniece/checkup
• Releases: https://github.com/emcniece/checkup/releases
• Travis: https://travis-ci.org/emcniece/checkup/

The emcniece/checkup/releases page linked here contains some other release naming patterns tested during the development of this feature. They ended up being pretty messy, so the master-auto overwrite pattern was chosen.

Alternatives

Though this master-auto tag update & overwrite pattern reduces tag and release clutter, there are drawbacks: Github doesn't always place this release at the very top of the release list each time it updates. Travis also seems to have the occasional problem with overwriting binaries during the deploy upload process - the release is still made and most binaries are uploaded, but if one upload fails it will not be included in the downloadable assets from the Github release page.

These problems can be avoided by making unique tags and releases. This results in a release for each master branch commit.

To do this, the .travis.yml config can be simplified:

language: go
if: NOT tag = master-auto
before_deploy:
  - cat PLATFORMS | xargs -L 1 -P 15 ./build-cross.sh
  - export TRAVIS_TAG=${TRAVIS_TAG:-$(date +'%Y%m%d%H%M%S')-$(git log --format=%h -1)}
  - git tag $TRAVIS_TAG
deploy:
  provider: releases
  api_key: $GITHUB_API_KEY
  file_glob: true
  file: "builds/*"
  skip_cleanup: true
  prerelease: true
  on:
    branch: master

This will create releases with the name of $TRAVIS_TAG, which works out to something like 20190505002539-0fa1a97.

A simpler tag could also be used, like auto-$(git log --format=%h -1)}.

Implementation Preparation

If you like this idea and want to merge, there is some quick credential setup that needs to happen: a Github token must be created and added to the Travis environment variables.

1. Create Github Token

1. Browse to https://github.com/settings/tokens
2. Generate a new token, give it a name
3. Check a single box: the public_repo scope
4. Click "Generate Token"
5. Copy token for use in next steps

2. Populate Travis CI ENV

1. Visit https://travis-ci.org/sourcegraph/checkup/settings
2. Under the "Environment Variables" section, add:
   • Name: GITHUB_API_KEY
   • Value: [token from step 1]
   • Display value in build log: OFF
3. Click "Add"

References

• Configuring encrypted Travis tokens
• Release overwrite example

[mholt]

This would be great. Thanks for preparing this. I am not sure I will have time to get to it very soon, but this would be a no. 1 action item. Thank you!