Using Travis-CI

I am wondering why aren’t we using Travis-CI for Ruby codebase in Foreman core. I’ve successfully used it for few of my gems and they seem to be free for open-source projects. I could not find out any limits they enforce for projects in free tier, but so far all testing was blazing fast.

It looks like we started using it when Node.JS was introduced, have we considered moving more things in there? If Foreman Core turns to be problematic, maybe we can consider moving other projects there. Smart Proxy comes to my mind first.

One issue is that you can’t use two languages in Travis. This means the configuration would be very complex. It’d also heavily overload the Travis free tier. When we do a few PRs to our puppet modules we can already feel the rate limiting and that’s nothing compared to what we test in foreman core.

Our team is preparing a proposal to update our testing infrastructure. This should allow us to modernize our testing while also being able to use a sponsor that only provides a Kubernetes cluster. is an example of how improved jobs can look. This is IMHO more powerful than what Travis can offer us now.


@lzap I am curious what the underlying reasons you are thinking about the use of Travis are. I read this as there are things about our current CI that are insufficient. For example, I see you note blazing speed which I translate to our CI is slow (and in some cases, it is!). As mentioned, a team of us are working on building our a set of improvements to make to CI. Any information you can share about issues you see, or wish list items would help us to build our list. I will be sending out an initial RFC once we’ve narrowed our set of items for futher feedback.

1 Like

Nothing in particular really, I pushed to a (different) project and it was working nice, was wondering what the reasons were. Two languages is really big issue for us.

You can do multiple languages in some cases, it’s not necessarily as pretty as it could be and you can’t easily do intricate matrices:

We can probably keep Jenkins for more complicated (including multi-language) environments, and use travis for simpler projects (plugins and extensions?). For example, pretty much all smart-proxy modules and providers can be tested via travis, but quite a few, even pretty trivial ones use jenkins.

Probably would reduce the load on jenkins a little bit too?

1 Like