ci: Migration from travis-ci.org to travis-ci.com

[hebasto]

There is a brainstorming question: could a migration from https://travis-ci.org to https://travis-ci.com improve our CI experience?

Refs:

• Announcing support for open source projects on travis-ci.com
• Existing Open Source Repositories on travis-ci.org

[emilengler]

Aside from the pricing model the two services are identical IIRC.

According to the website however:

Over the next several months, we’ll be migrating all travis-ci.org repositories and customers to travis-ci.com. Though this will not happen right away, you can go ahead and read more about what to expect in the docs.

I don't think there is any hurry todo as they will do the job for us.

[fanquake]

Going to close this for now.

[hebasto]

@MarcoFalke @fanquake

From Travis CI email:

We encourage you to migrate your existing repositories that are currently on travis-ci.org over to travis-ci.com as soon as possible, enabling you to identify any additional changes required to your code or configuration well in advance of the December 31st deadline.

[real-or-random]

Travis is apparently migrating resources from .org to .com. The deadline for migrating projects is 2020-12-31. That's why builds are slow, see
https://travis-ci.community/t/org-to-com-migration-deadline/10260

They suggest that people should migrate their projects to .com but as I understand, we can't do this right now due to permission issues. While the Travis "GitHub App", which you can install on a repo scope, has only read access, travis-ci.com asks for OAuth permissions which include write access to all owned repos of an account when signing up:
https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-why-is-travis-cicom-asking-for-write-access-to-my-repositories
https://travis-ci.community/t/is-there-a-plan-to-stop-travis-requesting-read-write-access-on-travis-ci-com-login/1364

[maflcko]

Travis for open source is effectively shutting down, so I don't think this is an option. See also:

• https://twitter.com/mitsuhiko/status/1323223738247192576
• https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
• https://travis-ci.community/t/oss-only-credits-request-processing-time-estimate/10446
• Personally, I had the same experience. Tickets asking for OSS credits will never be replied to.

[real-or-random]

I'm not sure if they're shutting down. It seems that even they don't know what they're doing: https://travis-ci.community/t/contradictive-information-in-the-ui-on-whether-credits-are-replenished-on-the-free-plan/10518 ...

But 1000 min per month is not great either. I don't think money would be the issue in the end but Travis seems to be unreliable from time to time. This also affects secp256k1. @MarcoFalke Ignoring the pricing, what's your experience with Cirrus here? Is technically superior or more reliable compared to Travis? I wonder if we should migrate secp256k1 to Cirrus.

Related: #19179

[hebasto]

Ignoring the pricing, what's your experience with Cirrus here? Is technically superior or more reliable compared to Travis? I wonder if we should migrate secp256k1 to Cirrus.

I've noticed 2 drawbacks on Cirrus CI:

• spontaneous VM failures (usually Cirrus itself re-runs such tasks)
• logs persistence is limited for 90 days

[maflcko]

I'm not sure if they're shutting down. It seems that even they don't know what they're doing

Effectively that is the same for the end user.

I don't think money would be the issue in the end

We used to send travis money, but the service stayed the same. Also, developers might want to fork a repo an try out changes without opening a pull request. They'd have to go through the extra steps to set up billing (and cancel it once they are done).

what's your experience with Cirrus here? Is technically superior or more reliable compared to Travis?

Cirrus doesn't have arm and s390x builds (or other exotic architectures), but at travis it was a community-best-effort offer only, so running exotic architectures through qemu instead seems fine too.
Also, we've seen intermittent vm crashes on cirrus on the shared cluster. Adding kvm:true to the config fixed those. (kvm:true will spin up a new vm per build, not interfering with other ci builds).
So while I can't vouch for cirrus, at least for us, they seem to be the best bet right now.

[maflcko]

spontaneous VM failures (usually Cirrus itself re-runs such tasks)

Are those still happening?

[hebasto]

spontaneous VM failures (usually Cirrus itself re-runs such tasks)

Are those still happening?

No, did not noticed failures lately.

[maflcko]

If you plan to run qemu-system for the secp256k1 repo, I haven't tried if that works with cirrus ci (we only use qemu-user). Alternatives could also be Circle Ci or Semaphore Ci, but I haven't looked into those either.

[real-or-random]

If you plan to run qemu-system for the secp256k1 repo, I haven't tried if that works with cirrus ci (we only use qemu-user). Alternatives could also be Circle Ci or Semaphore Ci, but I haven't looked into those either.

qemu-user should be enough for secp256k1. I was also playing around with Shippable which looked good on first glance and is still running fine but it seems that the project is dead (no activity in their github repo, not even activity or replies on twitter).

[maflcko]

For us travis wasn't suitable because it had too little RAM and builds timed out too often.

However, if travis ci has been working fine for you in the past, it might also be sufficient in the future. If you want to avoid adjusting the ci config for a new provider, you could hop on one of the travis paid plans and see if it works for you.

[maflcko]

The last TODO item is filed in issue #20467 , no need to keep this open.