Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
