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(a)gmail.com&gt; 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/cbd2c1fff05532974823da57... > (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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.

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.

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.

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: https://travis-ci.org/gsmet/hibernate-ogm/ https://github.com/gsmet/hibernate-ogm/blob/travis-support/.travis.yml 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&gt; wrote: > > Hi Sanne, > > On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > 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 >

Am 03.03.2016 um 09:57 schrieb Gunnar Morling <gunnar(a)hibernate.org&gt;: Interesting, do you know how do they do that? Run (unit) tests in a separate step after all modules has been compiled? It's notoriously hard to do with Maven, so I'm wondering how it's done. 2016-03-03 0:54 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > I just learned that Travis makes it easy to compile with one JDK and > then do something else with a different JDK - like running tests. > > That's very nice. With Jenkins we have to workaround such things by > creating multiple jobs and linking them together as dependencies. > > On 2 February 2016 at 14:46, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: >> 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: >> https://travis-ci.org/gsmet/hibernate-ogm/ >> https://github.com/gsmet/hibernate-ogm/blob/travis-support/.travis.yml >> >> 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&gt; >> wrote: >>> >>> Hi Sanne, >>> >>> On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; >>> 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 >>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev