travis.com CI pipeline config

[hugomrdias]

travis runs 2 pipelines every time we push to a branch/PR

• one for the branch
• one for the PR (uses the merge commit between PR branch head and target branch)

With the current config we run tests in 5 enviroments (linux, mac, window, firefox, chrome) and so we use 10 concurrent jobs per PR.

So the question here is, do we really need to run both pipelines on every commit to a branch/PR ? @ipfs/javascript-team

[daviddias]

The options being:

• a) run both (pay the whole cost === 10 runners)
• b) run only on branch
• c) run only on PR

b) has the problems that it would not run for external contributions (that are not originated in a branch from this repo)

c) would require that everyone’s continue to be a good citizen and get PRs open as early as possible with [WIP] tags and that no code gets merged without a PR.

[jacobheun]

With the current config we run tests in 5 enviroments (linux, mac, window, firefox, chrome) and so we use 10 concurrent jobs per PR.

What are we trying to solve here? Reducing cost, reducing parallel builds, something else?
It would be unfortunate to restrict the builds without a clearer reason why.

---

I think c is the most reasonable if we're trying to reduce costs and/or parallel builds. Something we'll lose is the ability to quickly experiment and push up a branch to see what happens with CI. However, I think this is easy enough to overcome through forks and enabling travis on your fork. It can be annoying, but the cost savings there are probably worth it.

[jacobheun]

Some notes on the recently added github Draft Pull Requests:

• If a PR is created as a Draft, PR builds do not run on Travis Ci, only branch runs happen.
• When a PR is marked as Ready for Review, the PR will eventually get picked up by Travis.

So this currently is an efficient way of avoiding double builds. People issuing PRs from forks would likely either need to not use draft PRs, or do a push after marking the draft PR as ready.

Update
I was testing with multiformats/js-multiaddr#84. Travis eventually picked up the PR after it was marked as Ready for Review.

[alanshaw]

In js-ipfs and soon js-ipfs-http-client we build only master and release/* branches and PRs like this: https://github.com/ipfs/js-ipfs/blob/e0b91ba07d5c77db04176a2ac37ec2ea241190de/.travis.yml#L7-L10