[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs