[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:15 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.

 Okay, this is done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636&id=63928a0b1294324249c69c8165e13c808e11a335
 commit] `63928a0b1294324249c69c8165e13c808e11a335`.

 > > 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?).

 This is also done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636&id=63928a0b1294324249c69c8165e13c808e11a335
 commit] `63928a0b1294324249c69c8165e13c808e11a335`.

 > > 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.

 Done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636&id=ca4168ea98818b1f291449596a7885671aefeded
 commit] `ca4168ea98818b1f291449596a7885671aefeded`.

 I'll squash all the branches once these new changes are approved.

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