CI: switch away from Travis?

[dhardy]

Given the recent news, should we switch away from Travis, e.g. to Azure (or one of the many others)?

I'm not very knowledgable about CI. We have a moderately complex configuation for Travis, which doesn't always behave the way people think it should.

Note that much of the platform-specific code is moving to the getrandom lib, which doesn't yet have CI configured. Rather than copy existing CI config over, it would be nice to use that repo to trial a new CI system, if anyone would be kind enough to help with this.

Also note we have an open PR on Travis config: #729

The Rust Infra team's investigation on this topic is partially relevant: https://internals.rust-lang.org/t/rust-lang-rusts-ci-provider-investigations/9487

[KodrAus]

Hmm, this is an interesting question. It's a bit of a shame to have to consider dropping Travis, after all its years of service to the open source community.

Maybe we could see which direction rust-lang moves in and consider going the same way? Their needs are a bit different, but could be a starting point.

[nagisa]

Azure’s pipelines apparently gives 10 whole concurrent runners that can run Windows/macOS/Linux.

[nagisa]

(Appveyor also supports linux hosts now, but something else would have to be found for macos then)

[KodrAus]

Azure Pipelines seems like a reasonable bet. I've spent some time with it over the last few weeks and found it to be usable, documented enough to get rolling with, and their free vuild agents are fairly capable. I'm not sure what the scope of their 10 concurrent jobs is though; whether it's per project or per owner account (I can't quite tell from their UI).

[dhardy]

To be clear, there is no reason we do need to drop Travis, at least so far. And since we need CI testing for getrandom soon, the most practical option is to copy over existing config from this repo.

[dhardy]

We have now set Travis CI up for getrandom and don't have any requirement to move away, so lets close this issue.