Hi,
FWIW, I also added Travis support to OGM (mostly to see if we could do it
easily with all the NoSQL databases supported) here:
What I also find interesting in Travis is that you can easily enable CI for
your own fork once the .travis.yml is committed to the main repository.
--
Guillaume
On Thu, Jan 28, 2016 at 6:26 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi Sanne,
On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
> I am a bit skeptical as we have CI working already on
ci.hibernate.org
> and having limited people we can't really afford to fix things which
> already work.
>
I perfectly understand that. I wanted to experiment it without bothering
you about it.
> To summarize what I like of Travis:
> - simple configuration
> - not much maintenance from our side
> - your recommendation counts
> - they pay the bills?
> - you say that it's very popular among Java developers.
>
> About the popularity point, you surprised me. I honestly thought that
> we should stay on Jenkins because that was the most popular one. Do
> you have some data to back that nowadays people are more familiar with
> Travis?
>
It's very widespread in the Open Source projects running on GitHub, either
in Java, Ruby, PHP, Python and so on.
HikariCP for instance uses Travis and there are a lot of others projects
using it:
https://github.com/brettwooldridge/HikariCP .
We use Jenkins at my company too for our private projects but we use
Travis for our Open Source ones.
> Finally I have been burned several times by not having "root access"
> on the whole thing. I guess Docker might make this reasoning moot now,
> but it's something to consider.
> It's also quite important that we make sure our releases are created
> in a reliable environment, so there's the trust issue of delegating
> the keys to the kingdom to a third party. I'd even like it we could
> start "signing" the artifacts we release as some users mentioned that
> this would be important for them.
>
Yes, Travis won't replace the release tasks. I think it's good for the day
to day builds and PR builds and we should only use it for that - if we
decide to use it.
> Sorry to be skeptical, I didn't mean to stress the negative aspects
> but to clarify that there are many aspects to consider for such a
> move.
> I'm definitely open to consider using it for a subset of jobs, like
> you mentioned the PR review system might be a good fit.
> It's also a good thing for sure to test in additional environments:
> can it also run jobs on Windows and OSX ? We're missing that.. we
> could fix the lack of Windows via AWS but that has a steep price tag..
> I'll rather volunteer an old laptop from home.
>
They have OSX support but it's sparse. It's mostly here to test MacOS and
iOS apps. They don't have Windows support.
--
Guillaume