Re: [RFC/PATCH v1] Add Travis CI support

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 4, 2015, 12:51 UTC
Message-ID: <e8f26179dc4f590073efc8a2f1bf23d2@dscho.org>
In-Reply-To: <xmqq612n2z3d.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On 2015-10-04 03:37, Junio C Hamano wrote:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley <roberto.tyley@gmail.com> wrote:
>>>
>>> Given this, enabling Travis CI for git/git seems pretty low risk,
>>> are there any strong objections to it happening?
>>
>> I still don't see a reason why git/git needs to be the one that is
>> used, when somebody
>> so interested (and I seem to see very many of them in the thread) can
>> sacrifice his or
>> her own fork and enable it him or herself.
> 
> To state it a bit differently.
> 
> If somebody says "I've been maintaining a clone of git/git with
> Travis webhooks enabled and as the result caught this many glitches
> during the past two months without any ill side effect.

Heh... given that Travis CI requires that .travis.yml file, nobody can really say that they have been using Travis CI *before* you add that file to `master`. If you make successful testing with Travis a *precondition* before adding that file, it is kinda asking for the impossible.

Now, I like Travis, even if I have used Jenkins previously (came as part of my previous day-job). And my experience with Jenkins (in the form of BuildHive) was pretty positive: it *did* catch a couple of breakages. Even with my Git fork.

But I agree with basically everybody who chimed in and said that the biggest bang for the buck would be made by enabling it on https://github.com/git/git.

The only cost I see is for that `.travis.yml` file to live in Git's source code. Small price to pay, if you ask me. If you do not want to use it yourself, that is fine. But I would like to ask for it to be included so that those of us who do want to benefit from Travis' testing are not precluded from doing so [*1*].

As far as I can tell, the patch is fine as-is. Although I would put the `before_script` commands into some file inside `contrib/`.

Thanks, Dscho

Footnote *1*: of course it would be possible to manually rebase the patch, or to set up a scripted version of that. That is very cumbersome, though, and the benefit would obviously be substantially diminished.