On Friday, 2 March 2018 at 06:07:25 UTC, Nick Sabalausky
(I'm posting this here instead of D.learn because it isn't
really a "How to do XYZ in D?", but rather to invite discussion
on high-level solutions to a problem.)
Here's a common problem:
1. A project (ex, some library) uses travis-ci (and/or other)
to ensure compatibility with a range of compiler versions. The
travis configuration file includes a manually-curated list of
2. CI tests are triggered by new commits/merges/PRs in the
3. New compiler versions are released.
Well, just for the record - imho adding your project to the
project tester is the best way to prevent regressions a priori:
add your project to the Project Tester (ci.dlang.io).
The Project Tester runs the testsuite of currently ~40 packages
on every PR at dmd, druntime, phobos, tools and dub
Imho it's te best way as a regression is caught _before_ the
change is merged and the need for the interaction is on the side
of the person who would introduce the regression (i.e. the one
understanding the change).
New projects can be added either by making a PR to the file to
 or pinging me.
but there are still limitations and downsides (ex: D tester has
FWIW it's not so limited and highly parallizable. It's already
configured to automatically create new temporary worker machines
in the Google Cloud  whenever there's more traffic/demand.
Considering the upsides of knowing that your project can _never
ever_break again is so huge that imho even if more workers are
needed, it's well-justified as there's quite a net gain.
 It currently uses the cheap preemptible VM machines in the
but Martin plans to migrate to Hetzner soon as there are too many
problems with those VMs.