On 08/08/2016 09:54 AM, Sebastiaan Koppe wrote: > On Sunday, 7 August 2016 at 23:08:34 UTC, Martin Nowak wrote: >> 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. > Thanks for taking the time to respond.
You're welcome. This is an important topic for us. > I agree with you. Library owners should test their code themselves. But > they don't. 24% of the packages don't build. We want better ranking of dub packages (mostly by download, but for sure also showing CI results [¹]). It's rather trivial to filter out low-quality packages b/c they're hardly used. [¹]: https://trello.com/c/CaYJwtBV/60-integrate-ci-results-with-dub-registry >> Just this short list I'm using for the project tester is hardly >> maintainable. > I don't need to maintain anything besides linker errors. It is quite > simple, I just run `dub test` and see what happens. If that doesn't work > I consider it a failed build. > >> https://github.com/MartinNowak/project_tester (uses Jenkins, no need >> to write yet another CI). > I would argue mine is simpler to deploy and have nodes join. Is it already usable? How to deploy then? I need to test https://github.com/dlang/druntime/pull/1602 and otherwise have to resetup my project tester for that. Adding more servers to Jenkins is trivial as well. >> Once a day is not enough b/c will feel responsible for breakages, we >> really need feedback before merging. > It is just a matter of resources. I choose nightly since it seemed > doable using just my own resources. Yes, but from past experience we know that people don't look at results, if you don't make it part of PR acceptance. >> - 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] >> ``` > Yes, that is quite nice. But that only gets triggered when the repo is > updated. Travis now allows cron scheduling, you still have to ask their support to unlock that. -Martin