git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date
Oct 4, 2015, 07:59 UTC
Message-ID
<vpq1tdb83nt.fsf@grenoble-inp.fr>
In-Reply-To
<CAPc5daXkn=C-D5RQCw2w+JrHn7XZA6X-P4F-PugRe-S4Z2RO0g@mail.gmail.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 7 quoted lines
> 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,

The very nice thing with Travis-CI is that it does not only test the repository's branches, but also all pull-requests. So, if it is activated on git/git, it will become possible to have a flow like

1) User pushes to his own repo, sends a pull-request,
2) Travis-CI notices the pull-request and builds it (no action needed
   from anyone),
3) Once the build is finished, the user can use e.g. SubmitGit to
   actually submit the code.

This has real benefits for the submitter (know if your code is broken early), for the reviewers (things like "you have a def-after-use" would be noticed by a computer before human beings start spending time on the review), and for you (some issues noticed before a topic enters pu).

There's no extra work for the user at all compared to the standard pull-request flow (nothing to do, just submit a PR), and a one-time setup for the project.

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.

This is much more work for the user (read: nobody will do it, actually nobody do it currently) and less convenient for reviewers (who have no way to check whether the build passed).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Previous: Johannes SchindelinNext: Junio C Hamano
Message 19 of 31 in “Add Travis CI support”
  1. Add Travis CI supportlarsxschneider@gmail.com, Sep 24, 2015
  2. Add Travis CI supportlarsxschneider@gmail.com, Sep 24, 2015
  3. Junio C HamanoSep 25, 2015
  4. Dennis KaarsemakerSep 25, 2015
  5. Johannes SchindelinSep 25, 2015
  6. Luke DiamandSep 25, 2015
  7. Junio C HamanoSep 25, 2015
  8. Lars SchneiderSep 26, 2015
  9. Matthieu MoySep 27, 2015
  10. Stefan BellerSep 28, 2015
  11. Matthieu MoySep 28, 2015
  12. Junio C HamanoSep 28, 2015
  13. Matthieu MoySep 28, 2015
  14. Roberto TyleyOct 3, 2015
  15. Junio C HamanoOct 4, 2015
  16. Junio C HamanoOct 4, 2015
  17. Dennis KaarsemakerOct 4, 2015
  18. Johannes SchindelinOct 4, 2015
  19. Matthieu MoyOct 4, 2015
  20. Junio C HamanoOct 4, 2015
  21. Dennis KaarsemakerOct 4, 2015
  22. Matthieu MoyOct 5, 2015
  23. Junio C HamanoOct 5, 2015
  24. Sebastian SchuberthOct 12, 2015
  25. Junio C HamanoOct 4, 2015
  26. Jeff KingOct 4, 2015
  27. Sebastian SchuberthOct 2, 2015
  28. Jeff KingSep 25, 2015
  29. Junio C HamanoSep 25, 2015
  30. Jeff KingSep 25, 2015
  31. Shawn PearceSep 26, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.