GitLab

Created by: bartlettroscoe

A KokkosKernels build failure was caught by the standard CI build:

• http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now

in the first CI iteration this morning:

• http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834087&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and

(which suggests the checkin-test-sems.sh script should have caught this build failure before the push). But this was only a test/example failure which does not disable KokkosKernels in downstream packages. (Note that we will lose this behavior once we do the single configure, build, and tests https://github.com/TriBITSPub/TriBITS/issues/183 ).

But it looks like @crtrott reacted to this quickly fixed the KokkosKernels in the latest CI build iteration:

• http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834513&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and

Note that since this was only a test/example failure for KokkosKernels, this would not have stopped anyone else's pushes using the checkin-test-sems.sh script where were only changing a package downstream from KokkosKernels.

Just added this issue to document this failure since it was interesting for a few reasons:

• The build failure should have likely have been caused by the checkin-test-sems.sh script
• The failure was seen and fixed in the very next CI iteration
• This was only a build failure for examples/tests so this would not have blocked anyone else's push to changes in packages downstream from KokkosKernels

Since Trilinos CDash info is forgotten pretty quickly (just a month or so).