I know gitlab.com has been working on IPv6 support everywhere, I'm not sure if they are at 100% yet. Have you tried there? That would give CI runs on GNU/Linux.
Also, https://eclips.is supports IPv6 in Amsterdam, so if Tor has credits there, then running a gitlab-runner there would be relatively straightforward.
.hc
teor:
Hi,
Want to help make Tor's CI go faster?
As part of the Sponsor 55 IPv6 work, I need to run Chutney IPv6 tests on every Tor commit, as part of Tor's CI.
We're currently running these tests with fast_finish, because:
- Travis CI only has IPv6 on macOS
- macOS Chutney tests take 20-45 minutes in Travis CI
But fast_finish requires allow_failure.
We can't have allow_failure on code that's we're modifying every day, so I'm going to make the Travis IPv6 Chutney job mandatory.
To speed up CI after this change, I'm going to make a new IPv6-only test-network target, and run it in the macOS CI: https://trac.torproject.org/projects/tor/ticket/33280
I've also identified one redundant Travis CI job that we can delete: https://trac.torproject.org/projects/tor/ticket/33195#comment:3
Overall, these changes should reduce total CI runtime by 20-35 minutes. Due to parallelism, the wall clock time should reduce by 10-35 minutes. We can squeeze the most benefit from the parallelism by sorting jobs in speed order (longest first): https://trac.torproject.org/projects/tor/ticket/33194
If you have any other ideas for making Tor's CI go faster, please let me know.
Slow CI is a particular issue for backports, because each 0.3.5 backport updates 9 branches:
- {maint,release}-{0.3.5,0.4.1,0.4.2,0.4.3} and
- master.
T
-- teor
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev