External Dashboard and CDash mails

Situation:

Some of you may know, some don’t, but VTK have a few external dashboards that are run nightly. There used to be a lot, but now, only RogueResearch dashboard (managed by @seanm ) are in this section.

How they work is that every night they will build the last VTK master with their configurations and reports any errors they may encounter on VTK dashboards, visible here:

https://open.cdash.org/index.php?project=VTK#!#Nightly+Expected

They also take a look at the mails of the commiters of the new commits of the day and send them a mail to inform that their commits may have broken something. Here is how these mails looks:

The “Nightly Expected” group has errors, warnings, or test failures.
You have been identified as one of the authors who have checked in changes that are part of this submission or you are listed in the default contact list.

Details on the submission can be found at https://open.cdash.org/index.php?project=VTK&date=2022-03-11.

Project: VTK
Site: RogueResearch19
Build Name: Mac12.x-AppleClang-dbg-Rosetta
Build Time: 2022-03-11 04:17:54
Type: Nightly
Total Failing Tests: 10

Failing Tests (first 5 included)
VTK::ViewsInfovisCxx-TestTreeMapView | Completed (Failed) | (https://open.cdash.org/test/638754713)
VTK::IOOggTheoraCxx-TestOggTheoraWriter | Completed (ILLEGAL) | (https://open.cdash.org/test/638754784)
VTK::RenderingAnnotationCxx-TestCubeAxes3 | Completed (Failed) | (https://open.cdash.org/test/638755314)
VTK::RenderingAnnotationCxx-TestCubeAxesWithYLines | Completed (Failed) | (https://open.cdash.org/test/638755335)
VTK::FiltersSelectionCxx-TestLinearSelector3D | Completed (Failed) | (https://open.cdash.org/test/638755368)

-CDash on open.cdash.org

Problem:

There is an issue with this situation.

As @seanm pointed out multiple time here and by mail, developpers will often breaks these dashboard and ignore the mail, usually without even realizing it. This reduce the quality and the usefullness of these dashboard.

This issue is caused by many factors:

  1. This external dashboard process is not documented at all in develop.md: https://gitlab.kitware.com/vtk/vtk/-/blob/master/Documentation/dev/git/develop.md#testing, new developpers have no way to learn about it unless reading topics deep in the discourse or asking around. This can cause incomprehension and prevent new contributors to contribute again.

  2. The mail is way too spammy, and inform on all broken tests, not only new broken tests, increasing the chance of the mail being ignored (I know I do).

  3. The mail is not specific enough as VTK rythm of developpement is too fast for a nightly approach, with around 20 commits a day, which means that the chance that a mail concerns actually you is pretty low and requires a deep investigation.

  4. This process is just too disconnected of our current approach of CI. What made sense in 2010 does not make sense in 2020 as the CI environnement has very much evolved, and for the better.

Possible Solutions:

I see a few solutions to this issue

  1. External dashboard is considered not part of the CI of VTK but the responsability of the external buildbot manager.

It means that when something broke, this is @seanm responsability to test, investigate and track down the commit which is source of the issue and ask the developpers to fix it if this is an actual issue.

This is what we have been doing the past few months, but there is strong limitations. First, it can be a lot of work which can appear at any morning for Sean. Delaying the work only increase the associated workload. More over, if the issue cannot be reproduced locally, the developpers has no way to test that any potential fix actually fix the issue.

  1. Improve the nightly process of testing in external dashboards

One of the main issue is that the mails are not specific enough and spammy. By improving the process we could send the mails to only the right person with an associated commit sha or MR. something like rerunning each failing test on each merge commit individually would probably narrow it down. The message could also be put on the MR directly instead of being set by mail.

This MR is breaking the following test on this cdash: [URL]

That doesnt fix the fix test issue mentionned earlier, and documentation would need to be improved.

  1. Integrate external dashboards in the CI process fully

If we care about certain configuration being tested, they should just be integrated in the CI process proper. It is not 2010 anymore, lets keep modernizing our process and integrate it all in gitlab. Either by retiring RogueResearch and deploying new machines on the shared runners network for this task or by using RogueResearch as dedicated gitlab runner for the VTK project.

I personnaly am more in favor of 3, as uniyfing process lead to more stability and less work for contributors, but I think this is very much open to discussion, and input from @seanm should very much be considered !

@seanm @ben.boeckel @berk.geveci @Francois_Mazen

1 Like

I think getting CI to cover most of the cases handled by RogueResearch machines is the best course. Of note:

  • older macOS targets (note that we tend to update our machines regularly due to EOL deadlines, so actually testing that things work on something like 10.10 is difficult)
  • warning flag sets (can be built on top of https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8843
  • some external deps (possible, requires some work)

I think just compiling while targeting macOS 10.10 (or whatever we deem to be the oldest supported version at least) should be sufficient for that part of this; Apple is usually decent about the mechanisms at least. I’ll also note that our upgrade path tends to make older Xcode versions unrunnable, so testing “minvers” (something we need for Linux and Windows too) there is pretty difficult.

Is there anything else RogueResearch is doing that I’m glossing over here?

Without much feedback from the community, I will keep doing 1:

External dashboard is considered not part of the CI of VTK but the responsability of the external buildbot manager.