On Saturday, 16 July 2016 at 20:34:49 UTC, Sebastiaan Koppe wrote:
I am aiming really low at first, but will eventually add things like memory usage, history, notifications, etc.

I actually don't think this makes sense. You're not in the position to maintain 1K+ packages, it's the library owners that need to test their code. Just this short list I'm using for the project tester is hardly maintainable. https://github.com/MartinNowak/project_tester (uses Jenkins, no need to write yet another CI).

I've already thought about many different aspects of this and here are the 2 things that are useful and might work out.

- Implement a tester that runs for every PR (just the other testers) and tests the most popular/important dub packages. Once a day is not enough b/c will feel responsible for breakages, we really need feedback before merging.

- Show test results of various CIs on code.dlang.org. Testing a dub package on Travis-CI is already a no-brainer. For example the following .travis.yml would test a package against all dmd release channels.

```yaml
language: d
d: [dmd, dmd-beta, dmd-nightly]
```

Reply via email to