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 <sa...@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.s...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
