Closed chadwhitacre closed 8 years ago
cc: @techtonik et al.
Ok for disabling IRC, but why don't build branches?
why don't build branches?
Because then we end up with two Travis builds per pull request, because of the way GitHub does pull requests. If I understand it right, GitHub automatically makes a merge commit for each pull request (I presume this is how they can determine whether the branch merges cleanly or not). Since the master
branch is involved in the merge commit, by constraining to just master
on Travis, we still get a test run for each commit on each pull request.
See gratipay/gratipay.com#3187 for where we introduced this on gratipay.com
.
Because then we end up with two Travis builds per pull request, because of the way GitHub does pull requests.
I look through Travis and can't see where PR commits are built on branches. Can you show an example of these two builds?
@techtonik Notice the two checks on #116, e.g., while there's only one check here.
Rather than test the commits from the branches the pull request is sent from, we test the merge between the origin and the upstream branch.
https://docs.travis-ci.com/user/pull-requests
That makes it sound like if you test on all branches and you test pull requests, then you get two builds per PR (one for the branch, one for the PR merge commit) ... but if you only test the master
branch and you test pull requests, then you get builds for each master commit and a build for each PR merge commit.
Now I see.
Looks like Travis couldn't understand this request and hung.
Rebased.
And merged!
Yay! :dancer:
P.S. @techtonik When you rebase can you leave the commit hash of the previous head in a comment for future reference? Thanks. :-)
leave the commit hash of the previous head in a comment
But when I force push it, it is gone, no?
@techtonik It's not listed on this PR anymore, but GitHub still keeps it around so we can browse it if we want to.
Ok. I'll keep this in mind.
cf. https://github.com/gratipay/postgres.py/pull/57