open-quantum-safe
Move Travis builds to GitHub Actions
EDIT: The Travis CI problem that this issue initially tracked has been resolved. For current efforts, please see discussion starting at https://github.com/open-quantum-safe/liboqs/issues/2068#issuecomment-2659511106.
It appears that Travis builds have not been happening for the past month. The page https://app.travis-ci.com/github/open-quantum-safe/liboqs shows the following message for me:
We are unable to start your build at this time. You exceeded the number of users allowed for your plan. Please review your plan details and follow the steps to resolution.
Tagging @bhess @dstebila @ryjones: perhaps we can use PQCA money to upgrade the Travis plan?
Thank you @SWilson4 for opening the issue. I’ve opened a ticket with TravisCI to investigate the problem further.
We get three users.
Who should I turn off?
I'm fine with not having access.
OK.
What builds do we get out of Travis? I would prefer to concentrate usage onto platforms we already pay for (GitHub, EC2)
OK.
What builds do we get out of Travis? I would prefer to concentrate usage onto platforms we already pay for (GitHub, EC2)
We use Travis for s390x and PowerPC. I agree that it would be ideal to have them on GitHub Actions.
OK. What builds do we get out of Travis? I would prefer to concentrate usage onto platforms we already pay for (GitHub, EC2)
We use Travis for s390x and PowerPC. I agree that it would be ideal to have them on GitHub Actions.
Strictly speaking, we don't need them in CI to begin with: They're testing a single vendor's HW and OQS does not promise CI in PLATFORMS.md for them.
Who should I turn off?
If this is for Travis access (?) I also don't need it: This is an IBM-only thing.
We are currently using the free service for OSS projects on Travis, which supports s390x and ppc64le. I reached out to Travis support, and it appears the build is working again. However, the ppc64le build seems to be stuck, and I will follow up with them to address the issue.
While consolidating everything onto a single CI platform would be ideal, as far as I know, GitHub Actions does not yet support these architectures natively. The only available option is an emulated environment, which is unsuitable due to its excessive running time.
Regardless of platform support commitments, I do like having tests that run on non–little-endian systems, if only to ensure that any patches we introduce don't break the property of an implementation being endianness-agnostic. This also helps upstream researchers catch endianness issues in their implementations that they might otherwise not be able to test.
I know, years ago, IBM would provide those platforms for CI for open source projects. Perhaps that's still true?
I know, years ago, IBM would provide those platforms for CI for open source projects. Perhaps that's still true?
Yes - see https://docs.travis-ci.com/user/reference/overview/#partner-queue-solution
The Travis builds for s390x and ppc64le appear to now working normally again, see https://app.travis-ci.com/github/open-quantum-safe/liboqs/builds/274164690?serverType=git
Ok to close the issue with this @SWilson4 ?
As it seems to happen a bit more regularly with these tests than with GH CI (or we more quickly take note of GH outages :) can I ask whether some "automation" would be possible to add to the Travis job to alert us of future outages of this sort (e.g., email to @bhess to take this up with Travis again) so we don't need to create issues each time?
I know, years ago, IBM would provide those platforms for CI for open source projects. Perhaps that's still true?
Yes - see https://docs.travis-ci.com/user/reference/overview/#partner-queue-solution
What I meant was for PQCA to reach out and directly manage them via GHA
I know, years ago, IBM would provide those platforms for CI for open source projects. Perhaps that's still true?
Yes - see https://docs.travis-ci.com/user/reference/overview/#partner-queue-solution
What I meant was for PQCA to reach out and directly manage them via GHA
If using IBM HW (as a big endian test env) in GH were possible that'd be great and allow us to get rid of the more unreliable Travis stuff: OK for your @SWilson4 ? Something you could look into @bhess?
What I meant was for PQCA to reach out and directly manage them via GHA
That would be ideal. I had the impression that the limitation was due to the lack of platform support for GitHub Runners beyond x64/arm32/arm64. However, after looking around, it seems others have successfully made it work. I'd be happy to take a look. @ryjones, would you prefer to request an instance on behalf of PQCA, or would you like me to handle the request?
If using IBM HW (as a big endian test env) in GH were possible that'd be great and allow us to get rid of the more unreliable Travis stuff: OK for your @SWilson4 ? Something you could look into @bhess?
Agreed, that would be excellent. Since Travis builds are now working again, I'm going to repurpose this issue to track the effort to get those builds onto GitHub Actions.
That would be ideal. I had the impression that the limitation was due to the lack of platform support for GitHub Runners beyond x64/arm32/arm64. However, after looking around, it seems others have successfully made it work. I'd be happy to take a look. @ryjones, would you prefer to request an instance on behalf of PQCA, or would you like me to handle the request?
Go for it. It's been years since I worked on z. If you need a hand with api keys or whatever, feel free to reach out here
Hey @bhess—just wanted to check if this was still on your radar. If you don't have bandwidth right now, maybe @ryjones can get the process started.
So the approach here would be:
- Reach out to IBM to get an s390x machine provisioned: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/
- Set up https://github.com/actions/runner on this VM
- Do all the configurey bits
- Add the workflow to GitHub actions
- Remove the workflow on Travis CI
One issue I see is that this only solves the s390x and not the ppc64le version.
Looks good!
I reviewed dotnet and it seems to at least have switches to enable ppc64le support. I'd need to verify that it can run Github actions Runner, but this looks promising.
Ah wait @ryjones, those both claim to be for Jenkins access - I'm not sure they'd be suitable for self hosted GitHub actions runners.
Well actually the ppc64le through OSUOSL seems to support setting up a VPS
but the Z system through OSUOSL seems to be just their Jenkins server.
Seems like a possible solution is then:
- ppc64le cloud stack through OSUOSL, then setup the self hosted runner
- reach out to IBM for Z, then setup the self hosted runner
you might reach out to OSUOSL and see if a VPS would be available.
you might reach out to OSUOSL and see if a VPS would be available.
on it!
Alright! The advice seems to be to reach out to OSUOSL for ppc64le and then request IBM for Z
@dstebila Do I have permission to fill out the form for IBM Z access on behalf of liboqs?
Let's get @bhess's opinion as well, as he has been our point person on the ppc64le and s390x CI.
But if this is going to be done with self-hosted runners, that is a concern. We've talked about those at various times in the past, and always chose not to do that because Github's documentation advises against self-hosted runners being used with public repositories.
But if this is going to be done with self-hosted runners, that is a concern.
From what I understand, this is the only mainstream way to get Github Actions with ppc64le and s390x.
My guess is that paying for Travis CI is probably the least effort approach to this, given the potential security concerns that self hosted runners for public repos may give.