Hi internals,
Since some time ago (not sure how long) our AppVeyor builds have been
timing out more often than not, to the point that I've started ignoring
failing AppVeyor builds entirely.
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.
Independently of that, it would be great if someone on a Windows
environment could look into the issue of AppVeyor timeouts. While PHP is
known to be slower on Windows, I find it somewhat odd that our AppVeyor
builds routinely take more than 60 minutes, while Travis builds usually
finish in 20 minutes. Based on build logs, running tests on AppVeyor often
takes ~45 minutes, while it takes ~15 minutes on Travis. Might there be a
legitimate performance issue here, that was caused by a recent-ish (last
month or so) change?
Regards,
Nikita
Since some time ago (not sure how long) our AppVeyor builds have been
timing out more often than not, to the point that I've started ignoring
failing AppVeyor builds entirely.
Indeed, this is particularly annoying for RMs.
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.
An alternative to consider is using Travis for Windows CI[1], too.
Independently of that, it would be great if someone on a Windows
environment could look into the issue of AppVeyor timeouts. While PHP is
known to be slower on Windows, I find it somewhat odd that our AppVeyor
builds routinely take more than 60 minutes, while Travis builds usually
finish in 20 minutes. Based on build logs, running tests on AppVeyor often
takes ~45 minutes, while it takes ~15 minutes on Travis. Might there be a
legitimate performance issue here, that was caused by a recent-ish (last
month or so) change?
To my knowledge, Appveyor “always” was way slower than Travis, and maybe
we're hitting the timeouts only now, since the size of the test suite
has increased. Since our Appveyor CI runs with slow tests enabled, it
might be worth a try to disable these. I've just submitted PR #3789[2]
to see whether that would make a big difference.
[1] https://blog.travis-ci.com/2018-10-11-windows-early-release
[2] https://github.com/php/php-src/pull/3789
--
Christoph M. Becker
On Sat, Feb 2, 2019 at 2:06 PM Christoph M. Becker cmbecker69@gmx.de
wrote:
Since some time ago (not sure how long) our AppVeyor builds have been
timing out more often than not, to the point that I've started ignoring
failing AppVeyor builds entirely.Indeed, this is particularly annoying for RMs.
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.An alternative to consider is using Travis for Windows CI[1], too.
It's an option, but I think we're generally better off using multiple CI
platforms to increase the number of parallel builds we get.
Next to the builds we already have, I think it would be very good to also
have a macos builder (this is supported by both Travis and Azure Pipelines,
but needs someone familiar with the platform to set things up) and a 32-bit
builder (probably a -m32 build on x86_64 Linux). That would bring us to a
total of six builds, which would probably make the Travis queue somewhat
slow if we used it exclusively.
Nikita
On Sat, Feb 2, 2019 at 2:06 PM Christoph M. Becker cmbecker69@gmx.de
wrote:I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.An alternative to consider is using Travis for Windows CI[1], too.
It's an option, but I think we're generally better off using multiple CI
platforms to increase the number of parallel builds we get.Next to the builds we already have, I think it would be very good to also
have a macos builder (this is supported by both Travis and Azure Pipelines,
but needs someone familiar with the platform to set things up) and a 32-bit
builder (probably a -m32 build on x86_64 Linux). That would bring us to a
total of six builds, which would probably make the Travis queue somewhat
slow if we used it exclusively.
Ah, makes perfect sense (a FreeBSD CI would be nice as well).
Regarding the execution time of the test suite, it might be sensible to
also have a look at PR #2822[1] and/or PFTT2[2].
[1] https://github.com/php/php-src/pull/2822
[2] https://git.php.net/?p=pftt2.git
--
Christoph M. Becker
Hi!
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.
Maybe also get Linux and macOS jobs there? We currently don't have CI
for macOS at all, AFAIK, and having different Linux environment probably
won't hurt either.
--
Stas Malyshev
smalyshev@gmail.com
Hi Nikita,
I can't be helpful here at all, because (shamefully) allergic to and bad at
windows, and no experience at all with azure.
But I would really like our CI to be restored to a thing that's useful,
instead of running two jobs on travis, and more or less nothing on av (most
of the time).
I remember having CI on travis for many configurations, including the ones
we actually develop with. Now we have two configurations and they don't
include no-zts-dbg which is what most internal devs are actually running.
Anything that restores anything like that former configuration, I'm a
huge +1 on ...
Anything that means we can run a useful windows CI, even if we can't move
any of the jobs that should be on travis over to Azure, I'm still a +1 on
...
Anything that means we have a mac build, the same +1 ...
Cheers
Joe
Hi!
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
which offers open source projects 10 parallel builds with unlimited
minutes. Assuming there's no other catch here, it might be worthwhile to
migrate our Windows CI jobs to Azure Pipelines.Maybe also get Linux and macOS jobs there? We currently don't have CI
for macOS at all, AFAIK, and having different Linux environment probably
won't hurt either.--
Stas Malyshev
smalyshev@gmail.com