Failing CI

[cmb69]

Description

For a couple of days now, we have some failing CI jobs, what has been pointed out and commented on in a couple of PRs. This ticket is just to keep track of that, and to have a central place to discuss.

• Some Linux jobs are failing because the mysql service can't be started; we might hit MSSQL containers crashing after recent update actions/runner-images#10649.
• Some macOS jobs are failing for 4 ext/curl test cases; I have no idea, why.

We should get back to green as soon as possible; I've already stumbled upon the broken window effect.

PHP Version

any

Operating System

Linux/macOS

[iluuu1994]

There are also these:

https://github.com/php/php-src/actions/runs/10984909451/job/30496065257

+ sudo service mysql start
Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xeu mysql.service" for details.

I was hoping these would resolve on their own, but still here...

[cmb69]

@iluuu1994, that was what I was referring in my first item.

Anyway, regarding the macOS issues see PR #16002.

[iluuu1994]

@cmb69 Ah ok, I misread. But we also have a MSSQL issue.

https://github.com/php/php-src/actions/runs/10986176141/job/30499161738

+ docker exec sql1 /opt/mssql-tools/bin/sqlcmd -S 127.0.0.1 -U SA -P '<YourStrong@Passw0rd>' -Q 'create login pdo_test with password='\''password'\'', check_policy=off; create user pdo_test for login pdo_test; grant alter, control to pdo_test;'
Error response from daemon: container b2bdae678b5eb8193a70a4ed4573e0292730e744cf2c69be2f642aace33a06ab is not running

[cmb69]

Actually, I misread: actions/runner-images#10649 is about MSSQL containers, not general containers.

[iluuu1994]

Also note that we use the pre-installed mysql service from the base image, rather than a docker image.

[Ayesh]

Curl tests seem to fail on WSL2 too, with the same error as the MacOS error.

[iluuu1994]

@Ayesh Which curl version are you using?

[Ayesh]

@iluuu1994 Curl 8.10.0.

I think your intuition is right, it indeed seems to be something broken between Curl 8.6.0 and 8.10.0. I'm trying with Curl 8.10.1 now.

[iluuu1994]

Thanks! I remember that previous curl issues appeared on macOS first, so I'm assuming they roll out new versions earlier.

[TimWolla]

FWIW some of the failures in a non-php-src extension of mine were likely caused by this change: curl/curl@ea6f5c9?diff=unified#diff-a1479d37f9dc2b43608da54abf14da3c2541b206d3f08d857b98f53b54ef91c8R81

[TimWolla]

All ext/curl tests for me pass locally in a debian:sid container with libcurl4-openssl-dev=8.10.1-1.

[Ayesh]

Test ext/curl/tests/bug48203_multi.phpt:

Passes on Curl 8.9.1
Fails on Curl 8.10.0
Passes on Curl 8.10.1
Passes on Curl latest commit

Because it works on latest (also as confirmed by @TimWolla) can we adjust the failing tests to skip on Curl 8.10.0?

[Ayesh]

I thought it was curl/curl#14898.

I also opened #16007 to skip the same four tests on curl 8.10.0.

[cmb69]

cURL 8.10.0 was a bad release; thus they published 8.10.1 shortly afterwards.

[TimWolla]

@Ayesh Good find. Thank you.

[Ayesh]

I tinkered with the mysql issue, and it looks like error 98, meaning there's another mysql process running so it cannot bind to the same port.

[cmb69]

See also #16010. I wonder whether we even need to start the service (again).

[KentarouTakeda]

This is due to a port conflict caused by running both the service container and locally. (I wonder why it worked like this until recently.)

I created a pull request in #16011 that fixes it to use only the service container with some exceptions.

I recommend using a container that allows us to easily change the version of the server being tested, but I think it would be fine to fix it by unifying it to running locally.

[nielsdos]

This is resolved, right? Or am I missing something?

[iluuu1994]

Almost. I believe nightly for 8.2 is now broken. I'll have a look in a bit.

[iluuu1994]

I backported the commit here: 50d5e96. Should be good now.