Tribits merger#1
Open
lefebvre wants to merge 177 commits into
Open
Conversation
This makes it easier to find the main TRIBIT_CTEST_DRIVER() function and its documentation. Actually, more functions should be created to make this main driver routine a little trimmer and easier to read. Build/Test Cases Summary Enabled Packages: TriBITS Enabled all Forward Packages 0) MPI_RELEASE_DEBUG_SHARED => passed: passed=230,notpassed=0 (1.05 min) Other local commits for this build/test group: bba4b6d, 75e9d75, 03b2e1e, 6f464ed
…iBITSPub#130) I forgot to update the TDD system for my changes for TriBITSPub#130. Since the TDD system is not under automated testing, this was allowed to be pushed. I was slopping in not finding this reference to the old function name. Sloppy on my part.
The updated CASL Fissile/Spy machines have a object dump that printe "RUNPATH" instead of "RPATH". I just updated the grep to look for "R.*PATH" instead of "RPATH" on Linux. Therefore, this should continue to work for existing Linux systems that have "RPATH". This should fix the failing TriBITS PPATH tests reported in PHI-4992. Build/Test Cases Summary Enabled Packages: TriBITS Enabled all Forward Packages 0) MPI_RELEASE_DEBUG_SHARED => passed: passed=230,notpassed=0 (2.30 min)
…riBITSPub#200, TriBITSPub#228) This is being used in TRIBITS_ADD_ADVANCED_TEST() first as part of TriBITSPub#228 but can be used in many other functions after that.
…ub#228) This is needed to allow TribitsAddAdvancedTest.cmake to be used in non-TriBITS project by just setting soem vars and including the file TribitsAddAdvancedTest.cmake.
This new feature makes it easy to copy a bunch of files to a newly created TRIBITS_ADD_ADVANCED_TEST() working directory. As part of this, I refactored the DriveAdvancedTest.cmake code to clean it up and make it (hopefully) easier to understand. A major part of this is that I added a new way to test TAAT() by running TAAT() in a nested CMake project so that TAAT() can actually check that TAAT() is printing the right things and behaving as it should. This will be very useful when more refactorings and performed and new feature are added to TAAT().
Add new TRIBITS_ADD_ADVANCED_TEST() COPY_FILES_TO_TEST_DIR block. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=260,notpassed=0 (0.64 min) 1) SERIAL_RELEASE => passed: passed=260,notpassed=0 (0.63 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.62 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.91 min) Other local commits for this build/test group: 3706c4b, 552e8c7, 8fe0fc5
…t new defaults (TriBITSPub#230) TriBITS was hardcoding the number of submit retry attempts to 25 and the delay between attempts as 120 second. That means that if there is a MySQL error (which is happening right now with attempted submits of SPARC build data as part of ATDV-84), then it will take 50 minutes to trying to submit before moving on!
This will be used in a refactoring related TriBITSPub#63.
…PL (ATDV-84, TriBITSPub#63) This is a fairly small change to the processing of TPLs that works for pre-installed TriBITS packages. Basically you just mark the TPL as "TRIBITS_TPL" in the TPLsList.cmake file instead of pointing to a directory or FindTPL<tplName>.cmake module file and then find_package(<tplName> REQUIRED) is used to get the parts of the TPL. At this point there are no automated tests to support and protect this. This is just a little refactoring (about 10 lines of code is all) that allowed us to have a prototype TriBITS build system for an APP (SPARC) treat pre-installed TriBITS packages as TPLs (see ATDV-84). I really don't want to even docuemnt this because I view this as just a small stepping-stone on the path merging the concepts and implementation of TriBITS Packages and TPLs. Therefore, I don't want to support this new TRIBITS_TPL TPL for very long and only for this one customer. I hope to be able to do enough refactoring of TriBITS so that an APP can just list these pre-installed TriBITS packages as packages in their Dependencies.cmake file and then have TriBITS automatically treat them as TPLs and look for them with find_package(). Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=260,notpassed=0 (0.70 min) 1) SERIAL_RELEASE => passed: passed=260,notpassed=0 (0.58 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.68 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.84 min) Other local commits for this build/test group: c25a7df, a8a1f9f
In CASL VERA, ${PROJECT_NAME}_TRIBITS_DIR is set to VERA/cmake/tribits which
is a symlink to VERA/TriBITS/tribits. This change makes it work correctly for
this one test.
…board' target (PHI #3913) These _AAO_ tests that involve breaking things and checking that the CTEST_DRIVER() code detects the breakages and reacts correctly appear to be a little fragile. The only fail when run with 'make dashboard' and not when run locally with just 'ctest'. What happens is that the build tool 'make' returns a different number of bulid failures and returns a different return code from 'make'. Also, in a few cases, the set of TribitsExampleProject executables that fail to build is different. Therefore, I have weaken these tests a little to allow them to pass. The tests are still pretty strong so I am not too worried. The alternative was to just disable them on CASL ORNL machines but that might mean that they might fail on other peopole's machines as well. I think it is better to weaken the test just a ltitle for all platforms than to just disable the test on a bunch of platforms. Time will tell if this was the right appraoch or not. Making this change is needed to allow the upgrade of Trilinos and TriBITS being tracked in PHI #3913.
I had forgotten to add this for the all-at-once appraoch. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=260,notpassed=0 (0.80 min) 1) SERIAL_RELEASE => passed: passed=260,notpassed=0 (0.61 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.60 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.71 min)
Since I think that newer versions of CDash just send out CDash emails as soon a triggering results are submitted, you might as well just add the update info right along with the initial configure and notes files.
I fixed two things here: * The test AAO_ST_ALL_BreakWithSubpackagesALib was failing due to the MixedLang package showing build failures for this build. This is very strange and suggests some behavior I don't understand. * Explictly set CTEST_PARALLEL_LEVEL in env. It was assuming the default of '1' but the HEAVY suite sets this to 48 in the env and was missing up the test. Now it is explicit. (This is the problem with env vars, they drill through everything.)
Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=260,notpassed=0 (0.72 min) 1) SERIAL_RELEASE => passed: passed=260,notpassed=0 (0.62 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.60 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.86 min) Other local commits for this build/test group: aa8b0a1
…th 'dashboard' target (PHI #3913)" This reverts commit b3354b4. I had to resolve a conflict that I don't understand why git conflicted it but I think I removed the weakening of the tests.
…ts on anasova for HEAVY build (PHI #3913)' I don't want to weaken these tests. I would rather have these tests run strong on a few platforms and not run on other platforms than to weaken them on all platforms. If needed, I can dig into why these tests are so fragile but there are other priorities.
The reason that these tests passed in some cases and not in others is that CTEST_BUILD_FLAGS was likely getting picked up in the env from a local 'make dashboard' and causing them to pass. Now by setting CTEST_BUILD_FLAGS=-k, we eliminate the parallel race conditions and we make sure that we build all targets that we can. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=260,notpassed=0 (0.72 min) 1) SERIAL_RELEASE => passed: passed=260,notpassed=0 (0.59 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.95 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=281,notpassed=0 (0.69 min) Other local commits for this build/test group: 5e6f409, 06031f4, e8e075f, 1465992, b3354b4, 7795ae3, 7d117e9, eb2ddb1, a349e79, a25f931, 87a6d0c, bba4b6d
…TriBITSPub#200) This catches cases that have caused major problems in Trilinos recently (and likely farther back than that).
Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=263,notpassed=0 (0.78 min) 1) SERIAL_RELEASE => passed: passed=263,notpassed=0 (0.75 min) 2) MPI_DEBUG_CMAKE-3.6.2 => passed: passed=284,notpassed=0 (0.68 min) 3) SERIAL_RELEASE_CMAKE-3.6.2 => passed: passed=284,notpassed=0 (0.74 min) Other local commits for this build/test group: fa6e3a9
Here's an initial implementation that allows a user to add default development branches to the .gitdist file in the form . master otherRepo develop thirdRepo master If those default development branches aren't specified, master is assumed. The user can then pass _DEFAULT_BRANCH_ to any command that accepts a reference and gitdist should replace _DEFAULT_BRANCH_ with the appropriate branch from the .gitdist file. The documentation for this feature can be accessed with --dist-help=default-branch.
The ability to use the environment variable GITDIST_MOVE_TO_BASE_DIR to change gitdist's behavior is now documented (see --dist-help=move-to-base-dir) and tested (see the gitdist_move_to_base_dir unit test).
Looks better formatted especially when using --dist-help=all. Also, moved --dist-help=move-to-base-dir above 'usage-tips' and 'script-dependencies' since I think that order seems a little better, especially for --dist-help=all. I also had to fix the tests to work when GITDIST_MOVE_TO_BASE_DIR is not set in the outer shell.
Tribits tutorial Issue TriBITSPub#190
Since this tutorial is in the tribits/doc/ directory, calling the 'tribits/doc/tribits_tutorial' is redundant. Therefore, I changed the name to 'tribits/doc/tutorial'. The driver script was trying to copy files to cupojoe.srn.sandia.gov. Also, it was removing output files automatically. How can you debug problems if you remove the output files? Added README.md file to state that this is still in develpment and may not build (I can't build it on my Linux machine). This will need some refactoring to make this cleaner, more robust, and easier to work with.
Hopefully this will avoid some confusion about this. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => Test case MPI_DEBUG was not run! => Does not affect push readiness! (-1.00 min) 1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min) 2) MPI_DEBUG_CMAKE-3.11.1 => passed: passed=328,notpassed=0 (1.09 min) 3) SERIAL_RELEASE_CMAKE-3.11.1 => passed: passed=328,notpassed=0 (1.17 min) Other local commits for this build/test group: 4f6f4c8
Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => Test case MPI_DEBUG was not run! => Does not affect push readiness! (-1.00 min) 1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min) 2) MPI_DEBUG_CMAKE-3.11.1 => passed: passed=328,notpassed=0 (0.86 min) 3) SERIAL_RELEASE_CMAKE-3.11.1 => passed: passed=328,notpassed=0 (1.20 min) Other local commits for this build/test group: ed2dde4
When the TriBITS tests where run recently under CASL VERA, a bunch of these failed because they had set CTEST_TEST_TYPE=Nightly in the env and that interacted with some of these TriBITS tests badly. I was able to reproduce the test failures bu just running: env CTEST_TEST_TYPE=Nightly ctest -j16 After setting back to default CTEST_TEST_TYPE= in the env, all of these tests passed. NOTE: I did not add any other tests for this case because I did not think it was worth the effort and the risk is very low. If some env var interacts with these tests and casues them to fail, it is easy enough to debug what is happening and then reset the offending env var (like I did here) and then get the tests to pass again. Where there is more risk is when you can set an env var and make tests pass that should otherwise fail (but I don't see how that can happen given the nature of these very strong tests).
…s#1761) Since the min version of CMake for TriBITS will soon be CMake 3.10.0 (see trilinos/Trilinos/#1761), we might as well just swtich to use CMake 3.11.1 for testing locally with TriBITS. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=328,notpassed=0 (0.89 min) 1) SERIAL_RELEASE => passed: passed=328,notpassed=0 (0.91 min) Other local commits for this build/test group: a24cefe
This will be needed once Trilinos and TriBITS offically make the min version CMake 3.10.0 (see trilinos/Trilinos#1761).
This will open the door to remove a bunch of conditional code for older CMake versions and will then allow for some refactorings that require newer versions of CMake. See trilinos/Trilinos#1761 for the motiviations for this.
…trilinos/Trilinos#1761) I took out logic to set the policy based on the CMake version of 3.3. That might change behavior of TriBITS projects so we will need to watch that. If that is a problem, we might just set the behavior to CMake 3.10.0 to be safe. That might make the behavior of TriBITS less variable with new CMake versions. I left in setting the policy CMP0054 which should make if() statements behave better w.r.t. to varaible and constant interpretations.
I also switched to all-at-once mode. I installed valgrind to allow running CTest -S memory checks. This now runs as many tests as my local checkin-test driver on crf450 with CMake 3.11.1.
…or all-at-once approach (TriBITSPub#269) This was needed when switching from the package-by-package appraoch to the all-at-once approach by default in Trilinos. See trilinos/Trilinos#1761. I also made it so that the list passed in to <Project>_EXCLUDE_PACAKGES can be seprated by commas ',' or semi-colons ';'. I added a unit test that protects both of these two behaviors. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=329,notpassed=0 (0.81 min) 1) SERIAL_RELEASE => passed: passed=329,notpassed=0 (0.88 min)
I added tests for passing and failing installs. I only implemented this for the all-at-once approach since that is all we need right now for ATDM Trilinos. But we could implement it for the package-by-package mode if needed without much trouble. Note that as part of this I fixed an oversight where build failures that did not cause test failures would be ignored in that all-at-once approach. That was wrong. Now if there are any build or install failures, it will assume that any (read that 'all') of the tested packages may have failed. See the long "NOTE" comment about this. Long-story-short, this will only really impact CI builds where there are build failures. If there are just test failures (the more common case), then only the packages with failing tests are flagged as failed and will be enabled on the next CI iteration. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=333,notpassed=0 (0.92 min) 1) SERIAL_RELEASE => passed: passed=333,notpassed=0 (1.06 min)
Note sure which commit broke this link but this commit fixes it.
…ub#270) Without this change, it was creating libs of the name 'lib<libname>.so.SOVERSION' (where 'SOVERSION' is literal!). I added a test that makes sure that a 'lib<libname>.so.SOVERSION' library is not created when the Version.cmake files does not exist. I also extended an existing test that check that the correct SOVERSION is added to shared libs when Version.cmake exists. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=334,notpassed=0 (0.87 min) 1) SERIAL_RELEASE => passed: passed=334,notpassed=0 (0.97 min) Other local commits for this build/test group: 585c062
…riBITSPub#271) Using 'WARNING:' causes CDash to count these as warnings. I have replaced all of the 'WARNING:' with 'NOTE:' for cases that are not actually warnings but just information that the user should note. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=334,notpassed=0 (0.97 min) 1) SERIAL_RELEASE => passed: passed=334,notpassed=0 (0.93 min)
Makes it easier to load modules and run utilities out of tribits/python_utils. Since tribits/ci_support depends on tibits/python_utils, this is not making things any less general. This will make it easier to write unit tests for cdash_build_testing_date.py.
This tool is to be used to make for robust installs of Trilinos in a date dir that matches the CDash testing day (see trilinos/Trilinos#2689).
This example shows how to put a raw CMake build system and a TriBITS build system side-by-side. There is also a "how to" based on this example. Hopefully this will be enough to explain how to accomplish this. Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=337,notpassed=0 (0.88 min) 1) SERIAL_RELEASE => passed: passed=337,notpassed=0 (0.99 min)
Build/Test Cases Summary Enabled Packages: Enabled all Packages 0) MPI_DEBUG => passed: passed=337,notpassed=0 (0.84 min) 1) SERIAL_RELEASE => passed: passed=337,notpassed=0 (0.95 min)
lefebvre
pushed a commit
that referenced
this pull request
Apr 17, 2025
…ptions-1 Adds cdash_analyze_and_report.py --filter-out-builds-and-tests-not-matching-expected-builds, fix filtering
lefebvre
pushed a commit
that referenced
this pull request
Apr 17, 2025
…po_fixes Fixed typo mistake seen in PR 464
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.