[tahoe-lafs-trac-stream] [tahoe-lafs] #2072: decide whether to enable Travis-CI for the main Tahoe-LAFS repo

[tahoe-lafs]

#2072: decide whether to enable Travis-CI for the main Tahoe-LAFS repo
-------------------------+-------------------------------------------------
     Reporter:  daira    |      Owner:  warner
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:  dev-     |    Version:  1.10.0
  infrastructure         |   Keywords:  security travis github brians-
   Resolution:           |  opinion-needed
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 I've used travis-ci on a different project (https://github.com/warner
 /python-versioneer). It's pretty nice. On that one, I revoked it's admin
 access after adding the post-commit hook which triggers builds. (from what
 I could tell, the main use case for that access was to simplify the hook
 installation, and could be done manually by copy/pasting some tokens from
 travis-ci into github's repo config page). I haven't explored the "mark a
 revision as passing" feature or what authority it needs.

 You can add an IMG tag to the README which will show the current build
 status for a single branch. That's a non-authority-requiring way to
 display build status.

 Is travis really capable of running our build and test suite? Its
 buildslaves are all donated by supporters, and impose a pretty strict
 timeout. The build-in-a-sandbox feature is pretty nice, but my general
 impression is that it's most suitable for small projects with simple
 dependencies (e.g. things which are pip-installable). I'll look at the
 test results you posted.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2072#comment:10>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage