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).

Reply via email to