Libseccomp: RFE: Transition from travis-ci.org to travis-ci.com

I logged into travis-ci.com, but they are still in the beta phase, thus we can't transition yet.

Bah! They are definitely not making this easy are they? ;)

Since the transition deadline is still "fuzzy" to put it mildly I'm going to pull this from the v2.5.2 milestone and let it float. We will still need to look at this at some point, but until Travis makes the move there is nothing for us to do here.

I just went to verify that the Travis build completed okay after some pushes and I was greeted by this message:

Since June 15th, 2021, the building on travis-ci.org is ceased. Please use travis-ci.com from now on.

... it looks like we need to figure this out, and soon.

I'm a little leery of Travis' new business model. It looks like open source will remain free (for now), but they have not made it easy. We may need to periodically request more "credits" from them.
https://docs.travis-ci.com/user/billing-faq/#what-if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

Ugh, that sucks :/

I need to refresh my memory on what you found out about GH Actions; it was far from perfect, but considering the Travis CI changes it might be the better option.

Here we go ... #299

Okay, having refreshed my memory on #299 I think the best option right now is to migrate to GH Actions and stick just to x86_64 CI builds for the time being. That seems like the quickest path to restoring PR/branch and code coverage tests with the least amount of headaches.

The lack of other arches/ABIs is troubling, but realistically we don't test every arch/ABI on a regular basis anyway (how could we?) so this isn't the end of the world. If it helps, while it isn't "CI" I do have a nightly job that runs on some private infrastructure which builds and verifies the libseccomp main branch on aarch64; if something breaks I'll notice it within ~24hrs. Hopefully we can figure out something better in the future (I have some ideas here ...).

@drakenclimber thoughts?

I think the best option right now is to migrate to GH Actions and stick just to x86_64 CI builds for the time being. That seems like the quickest path to restoring PR/branch and code coverage tests with the least amount of headaches.

Sounds good to me. I can own the transition since I already did it for libcgroup.

We've been using Github Actions in libcgroup for quite a while now, and it's worked quite well. The jobs were easy to transfer over from Travis.

The Github Actions VMs didn't provide a feature we needed in libcgroup (a full cgroup v2 system), so I recently created a VM on the Oracle Free Cloud and connected it up via Github Actions' self-hosted runner. It was easy to setup, and thus far has worked well. I believe the GH Actions self-hosted-runner logic supports aarch64, so this could be a way to continuously test ARM if we had a box we could point it at.

The lack of other arches/ABIs is troubling, but realistically we don't test every arch/ABI on a regular basis anyway (how could we?) so this isn't the end of the world.

Agreed. I have liked the range of architectures currently tested as it's occasionally found weird 32- vs 64-bit and big- vs little-endian issues. Prior to a release, we should (at a minimum) run the tests across other architectures. Perhaps we can recruit past contributors to help here.

(I have some ideas here ...).

I'm all ears. I wish I could take the best parts from GH Actions and Travis and put them in one CI.

(I have some ideas here ...)

Sorry, I should have been more clear. I meant I may have some ideas around supporting aarch64, not about Travis/GH in general.

Regardless, thanks for you work on this in PR #329.