How to configure Travis-CI to build pull requests & merges to master w/o redundancy
Solution 1:
I eventually found another GH issue (#2111) which gave me the idea to try enabling both PRs & pushes, but with a whitelist to restrict pushes to a specific branch. This seems to satisfy the criteria for my workflow. Here's what I did:
- Enable both PRs & branch pushes in the Travis settings for the repo:
- Change
.travis.yml
to white-listmaster
branch (i.e. only build pushes to master):
branches: only: - master
Test it by creating a PR with the
.travis.yml
change, and another PR with some empty commits to verify it works for forks too.Verify successful merge commit build from master.
Solution 2:
Just found in travis docs
Add to .travis.yml
if: type = push
alternatively:
if: type = pull_request
Solution 3:
Assuming you want to build all PRs, something like the following will do the trick. Enable both branch and PR builds on the settings page, and put this line as the first line in your travis.yml
:
if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~ /no-ci/)
This will attempt a push build on all pushes and a PR build on all pushes to an open PR, but will filter out any that don't meet the condition. You might need to modify this a bit - the clause about not building branches with no-ci somewhere in their name is obviously optional, and you may not have two branches that you always want to run builds on.
You can read more on conditions and conditional builds on Travis's site.
Solution 4:
The whitelist approach described in the accepted answer has some significant limitations. In particular, it doesn't support non-redundantly building arbitrary branches without opening a PR.
I opened an issue asking for a better solution.
Solution 5:
You can use next workflow if you want to test not only master
branch but some others branches too:
- Keep both "Build pushes" and "Build pull requests" ON
-
Add
branches:except
directive to your.travis.yml
:branches: except: - /^pr\..*/
In this configuration:
- any commit to branch
feature-A
will trigger the build - any commit to branch
pr.feature-A
will not trigger the build - if branch
pr.feature-A
is used in opened pull request then build will be triggered
Workflow example
- temporary WIP branch shared between several developers:
wip.feature-A
, any commit to this branch will trigger the build - when branch is ready to be merged to
master
you can rename it fromwip.feature-A
topr.feature-A
and open pull request - if while reviewing pull request you want to apply new fixes, just push to
pr.feature-A
On all the steps above only one build will be triggered.