PR build Trilinos_pullrequest_gcc_4.9.3_SERIAL and the nightly "Clean" build Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV are not the same

[bartlettroscoe]

CC: @dridzal, @crtrott, @srajama1

@trilinos/framework,

It looks like the PR build Trilinos_pullrequest_gcc_4.9.3_SERIAL and the nightly "Clean" build Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV are NOT the same!

The configuration for the PR build Trilinos_pullrequest_gcc_4.9.3_SERIAL for this PR shown here shows the Pthread TPL being explicitly enabled:

Explicitly enabled TPLs on input (by user):  Pthread BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 10
...
Final set of enabled TPLs:  Pthread BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 10

but the nightly "Clean" build Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV shown here shows that the Pthread is not being explicitly enabled:

Explicitly enabled TPLs on input (by user):  BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 9
...
Final set of enabled TPLs:  BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib X11 DLlib 10

This explains how code got onto 'develop' that was allowed to break the "Clean" non-MPI SERIAL build (see #3773 and #3803)

I thought the goal of the adding a (non-MPI) SERIAL PR build was to guarantee that the nightly "Clean" SERIAL would be clean?

[bartlettroscoe]

@trilinos/framework,

Can you just make the nightly "Clean" builds use the exact same env and *.cmake files as the matching PR builds? That would solve this problem, no?

[william76]

@bartlettroscoe
The Nightly Clean tests will be deprecated out at some point in favor of the dev->master Pull Request setup. It doesn't make a ton of sense to me to modify the serial build on the Clean track at this time. I'm fine leaving it as it's been as we decide what to do with it.

[srajama1]

@bartlettroscoe Thanks for getting to the bottom of this. I was bugging kokkos-kernels developers about the same thing, saying how we missed something that is in the nightly clean track. I would recommend the PR tester and the nightly clean tester be identical, so we avoid such issues in the future.

[prwolfe]

Siva,

This large of a blanket statement worries me. The current builds this issue refers to should be identical, but the final develop to master promotion builds will have a slightly expanded goal than the PR builds do. Basically integration is a bit different from delivery - in particular additional platforms and verification testing is often added. Please understand that there are likely going to be differences, for good reason, and that we will work to minimize those as we go.

Paul

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[github-actions]

This issue was closed due to inactivity for 395 days.