External Dashboard and CDash mails

Development
10

To clarify:

  • developer: anyone that contribute to VTK, unrelated to Kitware or have rights to merge
  • maintainer: someone that upload CDash results from a nightly runner to VTK CDash (unrelated to Kitware or actual VTK maintainers)

Miscommunication here. What I’m trying to say is that variations dont matter in the context of our discussions, as any external runner could be turned to an interrnal, premerge, runner.

It is not the many variations the issue, but the fact that certains variations can take too long to come back.

This is the only runner that make sense to run not premerge IMO.

You said yesterday all gitlab runners have to be in the kitware LAN, so how can I do that?

Not possible afaik, but @ben.boeckel or @berk.geveci can give more insight here.

It is possible to add you own flags to existing jobs, add new jobs and such in GitLab CI though, see below.

Strong disagree. IMNSHO, it should be the shared responsibility of the bot maintainer and the person that changed/broke the code. I think of it this way: Just because I find a bug you caused, doesn’t mean it’s my job to fix it, but I’m happy to help get it fixed together.

Sure, a warning one someelse runner can be considered an issue and fixed by the developper. But I strongly believe that:

  1. The tracking down of the issue is not the responsability of the developper, but of the maintainer
  2. The actual correction of the issue can be down by the developers but if the fix is complex, require a redesign, inccurs complexity, then the developpers can definitely NOT fix the issue and leave it open.

Let’s imagine the following scenarios:

  1. Developper add a feature
  2. A few years later, a maintainer add a external nightly runner to CDash, new warnings on the feature pop ups
  3. In that case, it is definitelly the maintainer responsability to track down and fix any warnings

Another one:

  1. Maintainer add a external nightly runner to CDash, to check for VS 2012, which is not supported officially (because not tested in the premerge CI btw)
  2. Developers add a feature that break on VS2012
  3. In that case, it is definitelly the maintainer responsability to track down and fix any warnings

Another one:

  1. Maintainer add a clang tidy external nightly runner to CDash, to check for tidy warnings that are not check on premerge CI yet
  2. Warnings pops up of course
  3. Developers add a feature add more warnings
  4. In that case, it is definitelly the maintainer responsability to track down and fix any warnings

With all these scenarios, the problem is that anyone, without consulting the community nor being reviewed by the developpers or even other maintainers for that matters, can add an nightly runners.
Kitwareans cant access these runners for on site debugging.
Developpers cant run these runners on the CI to check that their fix is working.

In the other hand, gitlab CI is a open CI system, where any developpers can add some more CI configurations or jobs. Kitware GitLab provide runners for the VTK project, which can be used.

Nightly, external to the repo, runners should be deprecated in the VTK project and maintainers should contribute their configuration to the GitLab CI jobs of VTK, relying on the runners of VTK.

Of course, if that is not possible, then external nightly CDash provided runners should be the responsability of the maintainers and warnings and errors on these runnners can be considered like any VTK issues, and fixed in the same way.

(On a side note, @seanm you may be interested by this: Documentation about reading and understanding CI results)