[hibernate-dev] [Search] Travis support
Steve Ebersole
steve at hibernate.org
Thu Jan 28 11:04:18 EST 2016
I do not know how to quantify "popularity", but I do know I have seen lots
of projects using travis for commit validation.
TBH my only concern would be access to the results. And that is more an
unknown. As I have never used Travis CI I do not know how its UI works.
Guillaume do you have project in Travis you can point us to so that we can
see?
On Thu, Jan 28, 2016 at 8:24 AM Sanne Grinovero <sanne at hibernate.org> wrote:
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list