Move Travis builds to GitHub Actions

[SWilson4]

EDIT: The Travis CI problem that this issue initially tracked has been resolved. For current efforts, please see discussion starting at #2068 (comment).

---

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?

[bhess]

Thank you @SWilson4 for opening the issue. I’ve opened a ticket with TravisCI to investigate the problem further.

[ryjones]

We get three users.

Who should I turn off?

[SWilson4]

We get three users.

Who should I turn off?

I'm fine with not having access.

[ryjones]

OK.

What builds do we get out of Travis? I would prefer to concentrate usage onto platforms we already pay for (GitHub, EC2)

[SWilson4]

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.

[baentsch]

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.

[bhess]

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.

[SWilson4]

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.

[ryjones]

I know, years ago, IBM would provide those platforms for CI for open source projects. Perhaps that's still true?

[bhess]

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 ?

[baentsch]

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?

[ryjones]

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

[baentsch]

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?

[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?

[SWilson4]

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.

[ryjones]

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