Travis CI re-enablement for s390x #15944
Comments
|
I wonder who has admin rights for our Travis account. @iluuu1994, would you know? |
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? |
I think you need to sign in, and activate the repo (see travis-ci/travis-ci#5629).
Having at least one CI job for big-endian architectures appears to be sensible. |
|
If Travis is unstable and not suitable for use, how about running nightly tests in a QEMU-based environment? |
|
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. |
|
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? |
|
@cmb69 Note that the instability was unrelated to the issue we experienced when we dropped the build. The issue was only the catalyst. |
|
@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. |
|
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? |
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'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. |
|
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). |
|
It's questionable whether a self-hosted runner (especially with custom, unsupported software) will be less buggy than a hosted one. |
|
Well, as they are saying: "Get CI running, or die trying." |
|
Well, I'm installing Gentoo as we speak in a partition on a system I have already, so I'm on the "die trying" part. 😵💫 I'll get the system up and play with the funny third-party runner at least. |
|
Well, I haven't died trying yet; I have Linux ready to go on the system, and I can give that runner tool a shot if someone who has the keys has time. |
|
@NattyNarwhal You should be able to test it in your fork. If it works, I don't mind adding it to CI as long as it doesn't become a maintenance burden. I think nightly would be enough, but if you keep it running just for php-src I guess we might as well run it on push. |
|
I have the branch |
|
It's running through tests finally, and even found some issues. (I hate debugging Actions though 😵💫) I'll document the environment/runner config, but most of the deps other than LLVM for *San are in the emerge action on my fork's branch. It doesn't run them because it's not containerized (yet) and I don't want to give the runner user admin privileges. The runner is also perhaps not the fastest - it's a partition with 32 threads out of the ~160 on that machine, and POWER8 is a little old. (Oh, and spinning rust does suck. It has enough RAM for a ramdisk though, so...) |
|
Bringing this up again: the preliminary ppc64be CI I set up on my fork caught a regression already (less because BE, more because it's a platform without JIT support), before it made it into a release. I think that makes it worth trying to get it into at least nightly runs on php/php-src. If I can get better performance out of it (or more runners), push would be really nice too. |
|
@iluuu1994 @cmb69 Issues seen in s390x travis builds have been resolved recently and jobs look stable for other projects. |
github-actions
bot
added
Status: Needs Triage
and removed
Status: Needs Feedback
labels
|
@iluuu1994 @cmb69 Could you please consider the above comment? Please let me know your thoughts. |
|
I think we're probably not interested in Travis, but I'm trying to get a different BE system going in GH-17258. For z specifically, I think we're looking into the IBM open source program for that. |
|
@AlocJose Not at this time, but thank you for your consideration. |
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
The text was updated successfully, but these errors were encountered: