-
Notifications
You must be signed in to change notification settings - Fork 577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch ATDM SEMS 7.2.0 build to use CMake 3.11.1 and all-at-once approach #3093
Switch ATDM SEMS 7.2.0 build to use CMake 3.11.1 and all-at-once approach #3093
Conversation
This version has better parallel running of tests.
This is just faster and we can use it since we are using CMake 3.11.1 and testing-vm.sandia.gov/cdash/ supports this mode.
Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection Is Not Necessary for this Pull Request. |
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Using Repos:
Pull Request Author: bartlettroscoe |
Status Flag 'Pull Request AutoTester' - Jenkins Testing: 1 or more Jobs FAILED Note: Testing will normally be attempted again in approx. 2 Hrs 30 Mins. If a change to the PR source branch occurs, the testing will be attempted again on next available autotester run. Pull Request Auto Testing has FAILED (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
|
@trilinos/framework, The above comment says that the GCC 4.9.3 and GCC 4.8.4 builds failed but there are no build or test results shown on CDash at: Can you look at the Jenkins jobs for these two builds and see what happened? Is there way that we can directly look at the Jenkins driver results to diagnose problems like this ourselves? |
Status Flag 'Pull Request AutoTester' - User Requested Retest - Label AT: RETEST will be reset after testing. |
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Using Repos:
Pull Request Author: bartlettroscoe |
Status Flag 'Pull Request AutoTester' - Jenkins Testing: 1 or more Jobs FAILED Note: Testing will normally be attempted again in approx. 2 Hrs 30 Mins. If a change to the PR source branch occurs, the testing will be attempted again on next available autotester run. Pull Request Auto Testing has FAILED (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
|
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Using Repos:
Pull Request Author: bartlettroscoe |
Status Flag 'Pull Request AutoTester' - Jenkins Testing: all Jobs PASSED Pull Request Auto Testing has PASSED (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
|
Status Flag 'Pre-Merge Inspection' - SUCCESS: The last commit to this Pull Request has been INSPECTED AND APPROVED by [ fryeguy52 ]! |
Status Flag 'Pull Request AutoTester' - Pull Request MUST BE MERGED MANUALLY BY Project Team - Master Automerge is disabled (in .cfg file) |
@bartlettroscoe
The Jenkins clients during Builds 1051 for gcc 4.9.3 & 756 for gcc 4.8.4 both had a Java crash and were unable to report to CDash. This kind of issue is being discussed with the frameworks team. |
FYI: It took three auto PR build attempts to get a passing set of builds to allow this PR to be merged. Due to this, we lost the chance to merge this yesterday so that we could see the impact today. Now we wait an additional day. (And this is in a case where no builds should be run at all because these changes don't impact any of the auto PR builds. We need to fix that logic in the PR testing system.) I just fear that if this occurs to frequently, then we may see people alter their workflows where they try to bypass the 'develop' branch more. But perhaps that will get people to learn git better and learn how to use side branches for collaboration and testing, so perhaps this additional delay is not a bad thing. |
I am confused. I see the output for 1051 and 756 when I look at the results here |
That is strange. Those results for the first tree builds were not showing up when I looked at this yesterday. Does that suggest a lag in the processing of updated *.xml files uploaded to CDash? How can we diagnose that? Doubling strange is that the builds Also strange is why are there no results shown on CDash for the GCC 4.9.3 build num 1055 or the GCC 4.8.4 build num 760 builds for the second auto PR build iteration shown above 17 hours ago. What happened to those builds? The auto PR tester says those builds failed, yet there is no results for these builds on CDash. Is this a case where the updated *.xml files are not being processed by CDash or were the *.xml files never submitted? Is there a way that we can look at the Jenkins jobs and see what is happening with these builds? |
The clone failed for both of these builds. This is a fairly common problem unfortunately. |
It could. I see no immediate evidence of that right now. I logged into CDash and looked under "Monitor / Processing Statistics" and nothing is backed up now. The other statistics shown also do not indicate backups, but at times things may get backed up. |
Digging into that, there are some possible signs of odd system issues at that time, and none of the failures look like real failures - 2/3 tests indicate they passed in the output, and the other one shows no sign of failure. The build failures have blank error output. It could be a hiccup at an inopportune time. |
CC: @fryeguy52
Description
This small PR switches the ATDM SEMS-based GCC 7.2.0 build to use CMake 3.11.1 and use the all-at-once approach with ctest/cdash. This should be the last ATDM Trilinos build to be swtiched over to the all-at-once approach.
Motivation and Context
CMake 3.11.1 is faster at running tests than CMake 3.10.1 and most of the other ATDM Trilinos builds are using CMake 3.11.1.
The all-at-once approach is faster at configure, build, and running tests and displays results better on CDash.
How Has This Been Tested?
I ran this locally on crf450 using:
That
console.out
log file showed:and I verified that CMake 3.11.1 was being used in the configure output file under Testing/Temporary/.