On Saturday, 6 August 2016 at 19:06:34 UTC, Sebastiaan Koppe
wrote:
I have just finished a first iteration of dubster, a test
runner that runs `dub test` on each package for each dmd
release.
see https://github.com/skoppe/dubster
Please provide feedback as it will determine the direction/life
of this tester.
I am planning on adding a web ui/api next to look around in the
data.
That are excellent news!
Some random ideas:
1) Send the packages a notification about the build error (e.g.
Github comment) - this should probably be tweaked a bit, s.t. it
doesn't spam too often for still broken packages
2) Allow easy, manual build of special branches for the core
team, e.g. let's say Walter develops the new scoped pointers
feature ( https://github.com/dlang/DIPs/pull/24), than it would
be great to know how many packages would break by pulling in the
branch (in comparison to the last release or current nightly). A
similar "breakage by shipping" test might be very interesting for
critical changes to druntime or phobos too.
3) Once you have the API
a) (try to) get a shield badge (-> http://shields.io/)
b) Make the data available to the dub-registry (->
https://github.com/dlang/dub-registry)
4) Assess the quality of the unittests. Probably the easiest is
`dub test -b unittest-cov`, and then summing up the total
coverage of all generated .lst files, but running with coverage
might increase your build times, though I would argue that it's
worth it ;-)
5) Log your daily "broken" statistics - could be a good indicator
of whether your hard work gets acknowledged.
6) Regarding linker errors - I can only redirect you to the open
DUB issue (https://github.com/dlang/dub/issues/852) and DEP 5
(https://github.com/dlang/dub/wiki/DEP5).
