We absolutely could -- that's why we forked over Dataflow's Travis configuration to start with. With Max's recent fixes to the Flink runner, this is very viable.
Travis vs. Jenkins is often a contentious discussion. Common arguments against Travis are: scalability / capacity, hard to schedule periodic runs, and inability to automate the release process. There are many pros too; e.g., automatic coverage on forked repositories. We are generally in favor of doing this through Jenkins for the pull requests, since that is our "official" CI. Many projects do this -- Apache Thrift is one example [1]. Work on this is in-progress on our side. Maintaining both systems is an extra burden, but I feel we'll end up there sooner or later. Thus, I'm also in favor of enabling the coverage that we already have. Let's have both for now, and we can always adjust later. I'll go ahead and file ticket(s) with INFRA. [1] https://github.com/apache/thrift/pull/932 On Tue, Mar 8, 2016 at 6:31 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Max, > > +1 good idea ! > > Regards > JB > > > On 03/08/2016 03:22 PM, Maximilian Michels wrote: > >> Hi Beamers, >> >> Quick suggestion: Could we enable Travis for the pull request of the >> GitHub mirror? At the moment we only have Travis for our forks. >> >> This would provide contributors with some feedback and also help us to >> identify problems with the pull requests. I think we only need to tell >> Infra to enable it for the apache/incubator-beam GitHub project. >> >> Best, >> Max >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
