Libelektra: Need to replace Travis CI

[kodebach]

As far as I understand this blog post, once Elektra is migrated to travis-ci.com (which will happen automatically at some point), Travis CI will basically be useless for us. It seems you only get 10.000 Credits (= 16.67 hours on Linux, or 3.33 hours on macOS) once. OSS projects can apply for more, but it seems you need to re-apply every time you need more. AFAIK the credits do not replenish monthly.

Other Projects seem to have the same issue: zopefoundation/meta#38

AFAIK everything the Travis CI builds do should be covered by Cirrus CI anyway, but we could also switch from Travis CI to Github Actions. It seems to be completely free for public repositories, according to the docs. There is also a migration guide and Github Actions allows self-hosting runners although that is not recommended for public repos because of security implications.

Features only in Travis CI

• [X] Mac builds also in Cirrus CI
• [ ] macOS+GCC 10
• [ ] Whitespaces in build dir

[markus2330]

Thank you for reporting this! I can do the registration but we can also drop Travis. Everything essential should be on our own Jenkins server, exactly for reasons like this.

As @sanssecours is also doing a lot of its maintenance work, he should be included in any decision. @sanssecours are you maybe today coming to our meeting?

[kodebach]

Our Jenkins server doesn't support macOS builds. But the macOS builds on Travis CI were always a problem.
Personally, I dislike how slow the Travis builds are. Cirrus CI seems to be much faster across the board. I have no experience with Github Actions, but a quick search suggests, it is faster than Travis and of course much better integrated into Github.

[markus2330]

I started to collect things which are only on Travis CI or were the reasons to have Travis CI (top post, please extend). If we can port some of these things to Jenkins it would be good anyway, even if we decide to keep Travis CI.

[mpranj]

Our infrastructure also does not have unlimited resources. At the time it was nice to distribute some of the workload to Travis and Cirrus.

@sanssecours already said that the Travis macOS build job is the only one, where macOS+GCC 10 are tested. We could try to migrate this to Cirrus. Note that Cirrus also has a concurrency limit (especially for macOS), so it would likely increase build times.

Regarding the Travis migration: we can try, but I do not think that we will somehow get more resources than before. We can discuss it quickly in the meeting, if anyone understands the new terms.

[sanssecours]

@sanssecours are you maybe today coming to our meeting?

Most probably not 😊. I think I will work at 17:00.

I would recommend to switch to GitHub Actions (for the macOS build job) as proposed by Klemens. Its free for public repositories and it seems to work reasonably well. I only created workflows for small projects until now though. The experience for larger projects like Elektra might be different.

[kodebach]

Our infrastructure also does not have unlimited resources. At the time it was nice to distribute some of the workload to Travis and Cirrus.

Agreed, I think migrating stuff to Jenkins is not a good idea, unless we expand our infrastructure. When there are many PRs Jenkins already takes quite long to work through the queue.

Note that Cirrus also has a concurrency limit (especially for macOS)

IIRC the limits on Cirrus are per User not per Repository. So two PRs by different people don't affect each other.
We also only have 1 full Linux build plus the Link Check and Documentation build on Cirrus right now. So there should be room for more Linux builds as well.

[mpranj]

Thank you both for the input! I just started the migration of the travis macOS build to Github Actions.

It's looking very promising.