[hibernate-dev] [Search] Travis support

[Sanne Grinovero]

Hi Guillaume,
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.
That said, this does look good, and it's certainly positive that we
can get some free computation resources from travis.org as our AWS
bills are getting high.

Definitely positive that the build configurations are versioned; we
have auditing of configuration changes on Jenkins [ci.hibernate.org]
but having it in git looks very nice. I'm not entirely convinced about
having the job configurations within the repository itself though -
there should be some freedom in running different combinations, and
try new job configurations without having to send pull requests; not
least branches will go out of synch.
There is a jenkins plugin which will take the job configuration from
the repository if we think that is important: I played with it but it
didn't seem very mature when I tried the first Alpha release.

The Infinispan and WildFly teams have switched from Jenkins to
TeamCity and are very happy with it; one of the reasons for them to
prefer it over Jenkins is that it does a great job at tracking
evolution over time of failures of a specific test: you can examine
the build stability from various perspectives. But it's not OSS so it
loses some points there.

Another strong candidate which we discusses some times is to use
Atlassian's Bamboo. That seems another very strong product, and would
have the additional benefit of great integration with JIRA which I
think we all love, and we get excellent help from Atlassian as they
sponsor our JIRA installation. Using Bamboo could help us streamline
some aspects of the release process and I hear it's very easy to setup
and maintain.

Finally, from some reviews and documentation I honestly think that GO
is actually the best platform (although not having much experience
with all these I'm not counting my own opinion very strongly). And it
was recently open sourced.

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?

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.

So I think that we might move some (several?) jobs to Travis but we'd
still want some job to run on our own platform - like the releases and
that implies jobs which test releases regularly - and then I'm not
sure if we want to have people necessarily familiarize with multiple
different UIs ?

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.

Thanks,
Sanne

On 27 January 2016 at 23:40, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> As mentioned in our last discussion, I explored adding Travis support to
> Search.
>
> The diff is here:
> https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a
> (yes it's short but it was a long road :))
>
> I had to raise a bit the JGroups timeout for one test and had to fix
> TestRunnerStandalone
> so that it effectively uses the configuration from the profile (this change
> is not specific to Travis and should be committed anyway).
>
> The result is here:
> https://travis-ci.org/gsmet/hibernate-search
>
> What I like in Travis:
> - The CI configuration is code and is versioned
> - Parallelization with a *lot* of resources
> - The ability to build a test matrix very easily
> - Complete isolation as each build is run in its own Docker container
>
> What is less cool:
> - The only way to get the logs is to ship them to AWS S3 - that said, I did
> it and it's pretty straightforward as it's well integrated (I commented out
> the code in the .travis.yml for now)
> - It might seem less flexible as we are depending on the Travis
> infrastructure (for instance, I created a ticket to ask for the support of
> JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you
> can do whatever you want: see https://github.com/Blazebit/blaze-persistence
> .travis.yml file for a comprehensive example
>
> So if we move to Travis, I think the regular builds could run on Travis and
> we could keep Jenkins for specific ones (deploy/release).
>
> I'll take a look at OGM tomorrow. Travis supports out of the box most of
> the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
> I'm pretty curious to see how it goes.
>
> Thoughts?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev