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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 4, 2015, 17:59 UTC
Message-ID: <xmqqio6m1pn2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <vpq1tdb83nt.fsf@grenoble-inp.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 14 quoted lines

> Currenty, to mimick this flow, we would need something like
>
> 1) User activates Travis-CI on his repo (each user would have to do
>    this, not just once)
>
> 2) User commits .travis.yml on top of the code to submit
>
> 3) User pushes to his repo
>
> 4) Travis-CI triggers a build
>
> 5) User removes the commit introducing .travis.yml, force-pushes
>
> 6) User submit the resulting code.

I do not think it has to be so convoluted. I know this would appear to be more or less a moot point, as the long term direction would be to enable one on git/git and do PR-initiated tests, but I am writing it here because I would really prefer that the CI configuration file that will be added to my tree is a "battle tested" one.

A motivated user who wants to send a patch to add it to my tree can:

 (1) Fork from an ancient place, e.g. v2.0.0, and add the CI
     configuration file.  Call that branch "travis".

 (2) Prepare topics that he wants to test (not related to "add CI
     integration to Git" topic) on its own topics, branching from my
     'master' or 'maint' depending on the target track.

 (3) Keep a branch that merges (2) with (1).  This could be a set of
     branches, one per topics in (2).

 (4) Have the CI monitor (3).

 (5) Make sure tests pass.  Send (2) out via whatever means,
     e.g. via SubmitGit.

And keep the set-up for a few months to make sure everything looks good, before sending (1) out via SubmitGit.