Remove branch CI and keep just pr CI

[mattdowle]

When PR is checked, there are 4 jobs (2 AppVeyor for /branch and /pr, and 2 for Travis for /branch and /push).
Branch means the branch is tested, I assume. It might be possible that the branch is behind master which is why this might be useful.
/pr and /push means master is tested as if PR were merged into master, right?

I've never really seen branch result different to pr/push result, though. But we have to wait for both to run which doubles the time to see if a PR passes after a push.

When non-project members do PR from a fork in their repo, I noticed (iirc) the PR just does pr/push check and not branch. Which makes sense because there is no branch in the data.table project in that case. And that works fine and great.

@jangorecki If that's all correct, could we remove the CI for branch? Keeping 2 out of the 4 CI jobs for /pr (AppVeyor) and /push (Travis) . And if so, how is that change made?

[jangorecki]

• Travis
  https://docs.travis-ci.com/user/web-ui/#Build-pushed-branches
  Disable "Build branch updates" in https://travis-ci.org/OWNER/REPO/settings

• Appveyor
  Here it works slightly different, branch builds are skipped if there is open PR:
  Do not start two builds on feature branch appveyor/ci#882
  Adding to appveyor.yml

skip_branch_with_pr: true

[HughParsonage]

I know I shouldn't but occasionally if I don't have access to a computer where I can easily build the package, I'll use Travis-CI on branch to test something for myself before opening a pull-request. Is it just waiting for the queue to clear that's the problem?

[jangorecki]

@HughParsonage so according to new settings only appveyor build will kicks in. If you want to check Linux then you can eventually check our gitlab mirror which runs multiple Linux jobs, but you will usually need to wait few minutes for pulling new branches from github to gitlab. https://gitlab.com/Rdatatable/data.table/pipelines

[mattdowle]

@HughParsonage Thanks for explaining that. I haven't been using branches in that way but maybe I should a bit more. Yes : it probably affects me more than others as I find myself waiting for CI tests to complete quite a bit. If the queue has built up it can take a while to start. Not a huge deal, but twice as fast (25mins down to 12mins) would come in handy on busy days, especially to see coverage results sooner. (25mins is already better than it was at about 40 mins, iirc).

[mattdowle]

@jangorecki So far so good. PRs are running 2 instead of 4 jobs and it's better.

One follow up: the last commit to master (34f90fb) was me changing CRAN_Release.cmd only, so I didn't create a PR for it. Looks like coverage is now missing for master though, causing PR #2755 not to show coverage. At least, according to the PR #2755 code cov comment :

Here's the link that comment points to : here.

Is there a way to ensure Travis (and therefore codecov stats) always runs for every commit to master, not just every merge?

[jangorecki]

For reference, same issue described in travis-ci/travis-ci#1147 (comment):

Can you elaborate on this: "There are ways to disable branch builds but allow for PR builds to continue."
How do we only build for master and Pull Requests ? I'd like to disable builds for other branches, as they always have a Pull Request for them.

And solution proposed in travis-ci/travis-ci#1147 (comment):

Whitelist master by adding this to your .travis.yml:

branches:
  only:
    - "master"

The merge commit will still trigger a build, because it's a merge into master (assuming your PR is against master, of course wink). As long as the branch whence the PR originates is not whitelisted, the commit on that branch won't trigger a build.

So activated building branches in travis settings again and opening new PR with suggested solution.