Repository navigation
CI: Enable GitHub Actions App for ppc64le (Power architecture) support #31810
Description
Hi scikit-learn team,
We’re reaching out to propose enabling CI support for the ppc64le (IBM Power) architecture in your repository, as part of a broader effort to ensure cross-platform compatibility in the scientific Python ecosystem.
We’re using a GitHub Actions (GHA)-based runner service provided and maintained by IBM to run jobs for the ppc64le architecture. This setup has already been successfully integrated into projects like:
We’d now like to propose enabling the GitHub Actions app in this repository to allow running CI jobs for ppc64le directly via GitHub Actions. This would support upstream compatibility and help ensure continued support for the Power architecture in scikit-learn.
Key Benefits:
🔒 Ephemeral and secure runners, isolated per job
🛠️ Maintained by IBM, requires no setup effort from your side
🔁 Integrates with existing GitHub Actions workflows
📚 Technical documentation and usage details:
https://github.com/IBM/actionspz/tree/main/docs
We’re happy to assist with the setup or provide any additional details the team may need.
Thanks so much!
Activity
betatim commentedon Jul 22, 2025
Thanks for opening this issue and having put in work to create testing infrastructure for open-source projects.
My initial reaction to this is to ask "where do we stand with respect to ppc64le support right now? Does it work? Is it a little broken? Is it a lot broken?" and "Do we want to promise to support this platform?". These are questions for @scikit-learn/core-devs
To add a bit of context, maybe @sandeepgupta12 you can give a short overview of what ppc64le is, where you'd fine processors like that, etc - I have to admit that I know the term Power PC, but that is about all (I think it is some ARM based thing?)
Could you explain why we need to add a GitHub App in order to use the runners? Asking because adding an app ussualy means granting the app some permissions/access rights - something that needs a bit of thinking about.
I saw in the linked Numpy thread that they raised the topic of not having (release) secrets in the jobs that end up running on the IBM runner. I think this is a good input for us to think about as well - can we, in general, reduce the amount of secrets available to runners? Do we need to do any work here?
sandeepgupta12 commentedon Jul 22, 2025
@betatim
Thanks for the thoughtful response!
To provide some context: ppc64le stands for PowerPC 64-bit Little Endian. It's the modern form of the PowerPC architecture and is primarily used in enterprise and high-performance computing (HPC) environments. You’ll commonly find it on IBM Power systems, including servers designed for AI workloads, scientific computing, and other data-intensive applications. It’s not ARM-based—though both are RISC architectures, they are entirely separate.
Regarding the GitHub App—yes, the runners we're using (hosted on IBM Cloud) require installing a GitHub App to securely authenticate jobs and associate them with the requesting repository. The app is scoped narrowly: it only permits workflow execution and does not access repository contents or secrets unless explicitly configured to do so. Projects like NumPy and Cryptography already use it successfully.
Also worth noting: these runners are ephemeral, meaning no data persists after the job completes. You can find more details in the FAQ here:
👉 https://github.com/IBM/actionspz/blob/main/docs/FAQ.md
jeremiedbb commentedon Jul 22, 2025
I'd say that ppc64le support is very very light right now. We don't ship wheels for this platform, however the conda-forge builds do build for this platform. But we skip the test suite on the ppc64le conda-forge builds (that might be for historical reasons that no longer applies, we could test enabling it again).
Besides that, we sometimes get issues for failing tests on ppc64le, but it's been quite some time that I didn't see a new one.
I think adding a CI job for this platform would be interesting, at least to see how far we are from being able to fully support this platform.
lesteve commentedon Jul 22, 2025
@sandeepgupta12 could you explain a little bit who is behind this effort (I have seen that many similar issues/PRs have been opened in PyTorch, matplotlib, numpy, etc ...)? Is it IBM who cares about better support in the scientific Python ecosystem?
Honestly for this kind of "exotic" platform request, the first thing I check is whether there is a numpy or scipy wheel, which does not seem to be the case.
Once there is a numpy and scipy wheel, I guess we may consider thinking about the "is it worth it?" question. How many of our users use
ppc64leand is it worth the maintenance cost?There are also security-related aspects to take into account because I am guessing this is using GitHub self-hosted runners 1 which has implications in terms of security. The GitHub doc says
Footnotes
The
IBM/actionspzonboarding doc seems to agree although "considered self-hosted runners" wording should be clarified ↩adrinjalali commentedon Jul 23, 2025
@sandeepgupta12 do you know if IBM (or those enterprises using the platform) are willing to pay for the support? This is not something our usual users need, and it would introduce significant maintenance cost on our side. So the effort needs to somewhat be justified.
sandeepgupta12 commentedon Jul 29, 2025
Thanks for raising this.
As mentioned in our FAQ, this service is provided at no cost. We do not provide direct access to our infrastructure, so we will handle the support.
My team and I are prepared to handle the maintenance workload needed to keep the ppc64le CI builds green. We’ll monitor the jobs regularly and take care of any architecture-specific or infra-related issues, so that the burden on maintainers remains minimal.
Any issues or coordination will be tracked via the actionspz GitHub repo.
adrinjalali commentedon Jul 30, 2025
Nice that your team handles all of that. However, if that's the case, then another alternative would be the following setup:
[ci ppc64le]This will ensure our CI doesn't get blocked due to ppc64le specific issues, and yet allowing to fix the issues and run CI on the main repo, only when necessary.
sandeepgupta12 commentedon Aug 1, 2025
Thanks for the clarification. Just to confirm — are you suggesting that we maintain ppc64le support through our fork, or were you envisioning something else? We’ll start by making the necessary fixes in our fork and then open a PR to your repository with the [ci ppc64le] tag, so the CI runs only when needed.
Also, a quick question — do you plan to upload the ppc64le wheels to PyPI eventually, since that’s our intended end goal?
Lastly, could you please open an issue in the actions-pz repository to install our GitHub App for CI integration — similar to this one: IBM/actionspz#21?
adrinjalali commentedon Aug 1, 2025
What I meant was not to have a fork and enable the CI on the fork, but to have a conda-forge feedstock like repo where its CI fetches the project and runs the build / tests on a CI. Whenever there are issues, you can be creative in solving them. I'm assuming your team would have access to such machines and therefore could test and solve the issue "locally".
adrinjalali commentedon Aug 1, 2025
This doesn't look like the right workflow to have at all. I suggest when you open an issue for a project to enable such CI, the project to be already authorised. It feels odd for you to come and open this issue, and then ask us to open an issue on your project asking you to allow us to run on your machines. It might be useful for you to get somebody more familiar with the vibe on this part of the ecosystem in your team 😉
sandeepgupta12 commentedon Aug 12, 2025
@adrinjalali, regarding the proposed “feedstock-style” separate repo for ppc64le CI builds and tests:
Could you please clarify who would be responsible for creating this repository?
Also, where is the recommended location for this repo — within the scikit-learn GitHub organization or elsewhere?
betatim commentedon Aug 13, 2025
The idea is that you/your team create this feedstock style repository, run the CI on it, when you discover a problem you can make a PR to the main scikit-learn repository and propose a fix
lesteve commentedon Oct 13, 2025
numpy has decided not add ppc64le wheels: numpy/numpy#22318 (comment).
PyTorch has decided not to add pcc64le wheels: pytorch/pytorch#141235 (comment).
On the conda-forge side, there is a discussion about ppc64le being too costly to maintain compared to actual usage and that feedstocks maintainers should feel free to drop it: conda-forge/conda-forge.github.io#2510
adrinjalali commentedon Oct 13, 2025
I think we can conclude that there's no action to be done at the moment from our side, since:
However, we might accept patches which specifically fix issues for that platform, given we can test it nicely. That means IBM needs to give free access to those machines to maintainers.
With that, I think we can close this issue.