+1! This will be really helpful when looking at my PRs; I basically get no
signal from the current state of the github UI, and this will restore that
to giving me very strong positive signal.

On Fri, Apr 28, 2017 at 6:22 PM, Davor Bonaci <[email protected]> wrote:

> Early on in the project, we've discussed our CI needs and concluded to use
> ASF-hosted Jenkins as our preferred tool of choice. We've also enabled
> Travis-CI, which covered some scenarios that Jenkins couldn't do at the
> time, but with the idea to transition to Jenkins eventually.
>
> Over the last few months, Travis-CI has been broken consistently, and
> several different kinds of infrastructure breakages have been added, one on
> top of another. This has caused plenty of cost and confusion. In
> particular, contributors often get confused as to which signal they should
> care about.
>
> At the same time, Jenkins capabilities have improved greatly: multiple
> parallel precommits are now supported, checked-in DSL support, pipelined
> matrix builds, Google's donation of Jenkins executors more than doubled,
> and others.
>
> So, based on the previous consensus and the fact the signal was broken for
> a long time, Jason and I went and asked Infra to disable Travis-CI on our
> code repository. (Website repository was disabled months ago.)
>
> I believe there should be minimal impact of this. The only two elements of
> the Travis matrix that were passing (still) are Python SDK on the Linux &
> Mac. Linux one can be trivially moved to Jenkins -- and I know Jason is
> looking at that. Mac coverage is the only loss at the moment, but is
> something we can likely address in the (near) future.
>
> I'm excited that we finally managed to unify our CI tooling, and can make
> efforts on improving and maintaining one system as opposed to two. That
> said, please comment if you have any worries about this or ideas for
> further CI improvements ;-)
>
> Davor
>

Reply via email to