Re: Removing Travis CI

Awesome, thanks a lot for this. On Mon, Jul 11, 2022 at 1:50 AM Nikita Popov <nikita.ppv@gmail.com> wrote: > > On Sun, Jul 10, 2022 at 10:07 PM Ayesh Karunaratne <ayesh@php.watch> wrote: >> >> Dear Internals, >> Historically, we have been using Travis CI for our automated tests, >> but since 2021 June, travis-ci.org has ceased operations, and no >> longer runs any builds. There was an Internals discussion >> (https://externals.io/message/112709) to move to the successor, >> travis-ci.com, but I don't think we ever moved there. >> >> Quoting Nikita from that thread: >> >> > We haven't been using Travis as our primary CI for a while already. We use >> > AppVeyor for Windows testing and Azure Pipelines for everything else. The >> > only thing Travis is still used for is a daily cron job that tests PHP on >> > "exotic" architectures like aarch64 and s390x. Having those builds is a >> > nice to have, but not particularly critical. >> >> As far as I see, Travis does not run php-src builds anymore; neither >> on push, nor on cron. >> >> https://travis-ci.org/github/php/php-src leads to a page >> that says the >> project was moved to travis-ci.com, and the linked page >> (https://travis-ci.com/php/php-src) throws a 404. I think we have now >> fully moved to GitHub Actions (thanks to amazing efforts by Ilija) + >> Azure Pipelines + Appveyor + Circle CI, so perhaps it's time we remove >> all the Travis-related code from php-src? I'd gladly volunteer for it, >> if we reach a consensus to remove it. > > > We use Travis CI to test architectures that are not available through other CI providers, in > particular aarch64 and s390x. Testing aarch64 is very important, because we provide a JIT > implementation for it. Testing s390x is useful, because it is a big-endian architecture. > > The build page you are looking for is > https://app.travis-ci.com/github/php/php-src. Just like other CI > runs, it is linked from GitHub's commit CI interface, so I'm not sure why you got the > impression that it does not run builds. > > It's unfortunate that we need to use multiple CI providers, because a single one does not > offer all relevant architectures and operating systems (Cirrus CI is used for their FreeBSD > support). > > Regards, > Nikita