As a VTK developper, and I know other VTK dev feel the same, we expect the CI we care about to be in the MR, not outside of it.
I don’t know anything about gitlab CI, but maybe there is some way to better integrate my bots with gitlab?
I’m afraid not. For security reasons, all the gitlab CI runner should be on Kitware internal network.
The gitlib CI is never green either.
I beg to differ. The CI is green (Apart for this one lone test that is currently being fixed by @spyridon97.) and we are crafting guidelines and enforcement to ensure that is stays green.
Another “easy” thing that would help is to actually turn on some warning flags on the gitlab CI. Currently the gitlab CI uses only compiler default warnings, which is a very low bar.
The CI process is open. Anyone can enable any warnings if they feel like it. I know that @ben.boeckel and myself will be happy to review such MR.
Testing is an infinitely large problem space, and pre-merge testing is great and covers a lot, but there’s so much more, and there’s only time to do some of it overnight.
In 2022, premerging testing is what matters imo. I’m not against somebody else testing what matters to them. I do have my own VTK build that test some stuff that I care about, but what the project cares about should be tested in the merge request, not after.