Stop all builds on the same PR when a new job starts.
- A: using travis-dedup.herokuapp.com with github hooks
- B: self hosting with github hooks
- C: directly via .travis.yml
Pro: simple / fast
Con: your travis token is sent via the web to a hosted service
- Go to Github settings
- Click
Generate new token
, use nameTravis Dedup
with scopesrepo (all)
anduser (all)
- Generate an access token
curl -X POST "https://api.travis-ci.com/auth/github" -d "github_token=YOUR_GITHUB_TOKEN"
- setup github webhook hook to
https://travis-dedup.herokuapp.com/github?repo=your_org/your_repo&token=YOUR_ACCESS_TOKEN
- add
&pro=true
if you are using travis.com / private travis - add
&branches=true
if you also want to dedup builds on branches (likemaster
or others) The hook sleeps for 5s before inspecting the builds so the newly pushed build are found too.
Pro: travis token is never sent over the web
Con: more complicated
- If
TRAVIS_ACCESS_TOKEN
is set, token parameter is no longer required - See
A
, but use your own heroku subdomain
Pro: no webservice required / token stays on travis
Con: slow to install gem / complicated with multiple envs
- encrypt token
travis encrypt TRAVIS_ACCESS_TOKEN=YOUR_ACCESS_TOKEN
- add it to your
.travis.yml
- Make your first build step:
before_install: gem install travis_dedup && travis-dedup your_org/your_repo $TRAVIS_ACCESS_TOKEN --pro
- use
global: + matrix:
- use something like
matrix: GROUP=misc
+before_install: "([ $GROUP = 'misc' ] && gem i travis_dedup && travis-dedup ... ) || [ $GROUP != 'misc' ]"
optionally generate the token at runtime via curl, but keeping the access token around is far less dangerous
Michael Grosser
[email protected]
License: MIT