Travis CI re-enablement for s390x

[AlocJose]

Description

Jobs have stopped running on Travis CI for s390x since 2024/08/09 and it says 'This is not an active repository. You don't have sufficient rights to enable this repo on Travis. Please contact the admin to enable it or to receive admin rights yourself.'
https://app.travis-ci.com/github/php/php-src
Php Travis CI was dropped via this commit 13f0411
All the issues related to Travis infra have been resolved. Would it be possible to kindly re-enable Travis CI for the s390x jobs? Please let me know if there is something I can do at my end to help add the support to CI.

PHP Version

master

Operating System

No response

[cmb69]

I wonder who has admin rights for our Travis account. @iluuu1994, would you know?

[iluuu1994]

I wonder who has admin rights for our Travis account.

I believe I do.

@AlocJose Thank you for letting us know. We discussed this when the build stopped working and decided to drop the build. It didn't add much value and frequently errored spuriously. Is there something I need to do on the Travis side?

[cmb69]

Is there something I need to do on the Travis side?

I think you need to sign in, and activate the repo (see travis-ci/travis-ci#5629).

It didn't add much value, […]

Having at least one CI job for big-endian architectures appears to be sensible.

[zeriyoshi]

If Travis is unstable and not suitable for use, how about running nightly tests in a QEMU-based environment?
This can be achieved relatively easily using Docker (although it will take an incredibly long time due to emulation)

https://github.com/zeriyoshi/php-containers-development

[iluuu1994]

Yes, this is what has been suggested. We could try to cross-compile to some other architecture and then run tests using QEMU. However, I suspect this to be very slow, so maybe something we only run once a week or so.

[cmb69]

That instability may have been caused because php-src was not enabled via Travis, but only via GH. Why not give it a try again?

[iluuu1994]

@cmb69 Note that the instability was unrelated to the issue we experienced when we dropped the build. The issue was only the catalyst.

[iluuu1994]

@cmb69 I don't object to re-adding Travis in the meantime. It's unlikely we'll find an alternative big endian platform quickly. That said, the Travis build has sometimes not worked properly for weeks, so it's not like it was super reliable to begin with. We also have some people working on IBM, e.g. @NattyNarwhal (from what I understood). Let me know what your preference is.

[NattyNarwhal]

I actually do have some spare Power hardware (mostly all POWER8) available for CI purposes. What would be the best way to make it available? I could rack it up on some personal infrastructure, or would it be better to put it in the hands of i.e. the foundation?

[cmb69]

That said, the Travis build has sometimes not worked properly for weeks, so it's not like it was super reliable to begin with.

Yeah, but I still wonder if this is a general Travis issue, or whether this was because we apparently never enabled php-src via Travis, but instead had enabled Travis via GH. If it is not much work, I'd give Travis a try; if it is still unstable, we can shut it down again.

I actually do have some spare Power hardware (mostly all POWER8) available for CI purposes. What would be the best way to make it available?

I'm afraid that is not supported as self-hosted runner. I don't know if there are work-arounds to still integrate such a machine into GH CI.

[NattyNarwhal]

I think there's at least one third party implementation of the runner that runs on platforms that GH's doesn't, plus we could deploy some other CI thing (though I think everyone here wants to stick with Actions).