#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs