[tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-------------------------------------------------+-------------------------
 Reporter:  catalyst                             |          Owner:
                                                 |  patrickod
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  continuous-integration ci testing    |  Actual Points:  .5
  best-practice unit-testing new-developers      |
  travis                                         |
Parent ID:                                       |         Points:  .5
 Reviewer:  catalyst                             |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by isis):

 Replying to [comment:14 catalyst]:
 > Thanks!  This is very useful to have.  Technically this looks mostly
 good to me, with a few minor (mostly documentation) nits.
 >
 > I have a GitHub account with Travis CI enabled.  I confirm that tests on
 `bug22636_0.3.1` [https://travis-ci.org/tlyu/tor/builds/254404828 pass]
 and tests on `bug22636_0.2.4` [https://travis-
 ci.org/tlyu/tor/builds/254484617 pass].
 >
 > I'm trying to understand the differences between this and our Jenkins
 configurations.  It looks like our Jenkins config turns on `--disable-
 silent-rules` to get a bit more verbosity on the compile lines; should we
 do likewise?

 Yes, this is a good idea.

 > Jenkins also does `make check` instead of `make check-spaces` and `make
 test`.  Is there some reason to not do `make check`?  I think that doesn't
 significantly increase the run time, but I haven't measured the difference
 yet.

 This is probably a good idea, as it tests more. The output might be a bit
 tricky to get, because the way it is configured right now, if some step
 fails, the whole CI build will fail fast.  So e.g. if compilation failed,
 don't waste more time testing.  Also if `make check-spaces` fails, your
 commit needs to be fixed up anyway, so again don't bother wasting time
 testing.  Whereas if we run `make check` it does all this in one go, and
 if it fails some step, it only reports that at the end of everything.
 Also, all the output that we'd need in order to see what failed gets
 shoved into a file (but possibly I can get that output with a `after-
 script` stanza?).

 > Commenting the `.travis.yml` with brief explanations of these choices
 might be a good idea.  Also, squashing the commits somewhat would be good.
 Some of the commit messages, like the ones involving Rust config choices,
 might work better as comments in `.travis.yml`.

 Yes, this is a great idea.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22636#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online