Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> I still don't see a reason why git/git needs to be the one that is >> used, > > The very nice thing with Travis-CI is that it does not only test the > repository's branches, but also all pull-requests. OK, that is the first real argument I heard for enabling it on git/git that is worth listening to. Practically, it has little value to run CI (whose only test is to run "make test") on branches that I publish in that repository. By the time a change hits that repository, "make test" has been run on my end already, and the only thing the CI would catch is platform dependent glitches (e.g. Windows and Mac), dependency-related ones (e.g. p4), or breakages I already know about [*1*]. But we _do_ want to see tested patches submitted to the list so that reviewers do not have to waste time on obviously bogus patches reviewing (and the integrator wasting time on deconflicting). A test that is PR-initiated would give us a real value there. The repository that is used for the PR-initiated test does not have to be git/git (it only has to be a central well-known repository), but similar to arrangement for SubmitGit, I agree that git/git would be a good candidate for that "central well-known" one. There is not much point in introducing another "if you want your topics tested, throw a PR against this other repository". So,... I would not mind a patch that adds a CI configuration file (I would really prefer it to be a battle-tested one, though) to my tree, and I would not mind if CI is enabled on git/git, if Peff or somebody more security-minded than me thinks it is safe to do so. One final question. Which configuration file does the CI use when running a PR-initiated test? The one already in the repository i.e. the target of the proposed pull, or the one that is possibly updated by the PR? I am wondering if that can be an avenue for a possible mischief. Thanks. [Footnote] *1* I occasionally do push out 'pu' with known breakages (e.g. the recent 'lmdb' one) to make sure people are running the test suite so that they will work with the topic author to resolve the issue without having to wait for me to tell the topic author about it; letting CI catch that kind of breakage would not add much value, because it is already known ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html