I cannot browse into the details. For example all tests passed but when I click on the number there's an empty page saying 0 tests passed sucessfully. Same for warnings etc...
Description
Related Objects
- Mentioned In
- T27910: 2020 Week 43 (Late October)
rMITK1eb820c49757: Merge branch 'feature/T25882-MITKOptions' into develop
rMITKebe44be1fd0d: Merge branch 'feature/T25882-CDashAuthorization' into develop
T27784: 2020 Week 39 (Late September)
rMITK923677a343b7: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITK2661a3470aff: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITKac0bf7f5dce1: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITK94c50addf1ed: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITKa3ba7555dc9b: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITKfc5d8c5491d1: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITK8be1a44b0d0d: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITKf83f03607806: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITK9973ea6ada29: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
rMITKaf09e331a755: Merge branch 'bugfix/T25882-RewriteDashboardScript' into develop
T27695: 2020 Week 36 (Very Early September)
rMITK899caed2f76e: Merge branch 'hotfix/T25882-CDash-v2.6' into develop
rMITKf0e722f6a65d: Merge branch 'hotfix/T25882-CDash-v2.6'
T27033: Clean up stale remote branches
rMITK77007566ef1e: Merge remote-tracking branch 'origin/master' into T25882-RewriteCTestScript
Event Timeline
Things I found so far:
- There is/was a missing slash in an XML tag of a file that specifies our subprojects and their dependencies
- As soon as the MITK-Configure project is submitted, a CDash error is logged: This build already has a configure {"fn":"BuildConfigure::Insert", ...}
- The actual issue seems to be that we do not submit a Done.xml file at the end of the build
Without the Done.xml submission, the submission won't get rid of the pending status and the details like errors, warnings, and modifications are not parsed and inserted into the database.
To get an overview of MITK subprojects:
- Subprojects are defined in top-level CMakeLists.txt:445 (CTEST_PROJECT_SUBPROJECTS)
- Subprojects are written into <BINARY_DIR>/CTestConfigSubProject.cmake
- Additional subprojects can be appended to CTEST_PROJECT_ADDITIONAL_TARGETS
- Subprojects are also written into <BINARY_DIR>/Project.xml
- Basically same subprojects are written into Project.xml for superbuild and MITK build (superbuild-version adds SuperBuild as project dependency to subprojects)
- Documentation subproject is hard-coded into Project.xml with all other subprojects as dependency
- For each subproject defined in top-level CMakeLists.txt a custom target is created except for "Unlabeled"
- Not sure if "Unlabeled" is really used in general as it can only be found a few times in the source tree but seemingly only in queries
- mitk_create_module() has parameter SUBPROJECTS
- If not set but MITK_DEFAULT_SUBPROJECTS variable is set, it is used instead
- Else, "MITK-Modules" is set as subproject
- Subprojects and "MITK" are added as labels to all sources
- If the module is not header-only, the labels are also added to the target and the module target is added as dependency to the subproject targets
- module subprojects can be queried after the function call via MODULE_SUBPROJECTS
- mitk_create_plugin() also has parameter SUBPROJECTS
- If not set but MITK_DEFAULT_SUBPROJECTS variable is set, it is used instead
- Else, "MITK-Plugins" is set as subproject
- Only the target is labeled, not the sources
- Also, no "MITK" label as in modules
- mitk_create_executable() basically uses mitk_create_module()
- mitk_create_module_tests() basically uses mitk_create_executable()
- Subproject and "MITK" labels are added to the tests
- mitkAddCustomModuleTests() does the same
- mitkFunctionAddTestLabel() appends a label to a test
- Only used by DICOMTesting module for tests named DICOM_Load_${input} where the name is also added as label
The This build already has a configure error in the CDash log file is triggered because we submit the Configure part twice: for the superbuild and for the MITK-build. However, it seems that this part is only allowed to be submitted once.
@kislinsk Currently the Dashboard, does not show the error or failed tests if you click on the Number in the table. Is this part of this issues or another one?
This is part of this issue (actually the main reason). It is already working in my local version but I have to make a few adaptions to get a stable minimum working version for production.
Todos
- MITK_BUILD_OPTIONS for MITK cache vars
- Check why there are documentation errors "lost edge a b" but when I manually "make doc" on the client, it works
- OpenCV somehow seems to trigger Ant errors on Ubuntu only during the first build (problem in Nightlies)
- First time build of MatchPoint triggers many warnings as errors on macOS
I think I fixed the OpenCV Ant issue by updating the volume snapshot for our Ubuntu 20.04 cloud instances to include the environment variable ANT_HOME=/usr/share/ant.
I finally found the source of the documentation errors by accident. It was a dot digraph with invalid flat edges between record shapes. I changed the shapes to boxes and it should work now.
macOS MatchPoint errors that are actually just warnings should be fixed now as well. It's a bug in CMake/CTest and the workaround is to use launchers: https://gitlab.kitware.com/cmake/cmake/-/issues/20832
As unknown sites are appearing on our dashboard, we should introduce authentication:
https://blog.kitware.com/cdash-authenticated-submissions/
Sigh. Just one time I'd like not to stumble over bugs when dealing with CDash. I implemented the authorization, double-checked that the proxy does not throw away the authorization HTTP header, watched the cdash database, and figured out that as soon as CDash is comparing a valid token... it deletes it from the database.
Found the bug in CDash. In app/Model/AuthToken.php:51 the "special value" 9999-12-31 23:59:59 is inserted into the database whereas the maximum value for TIMESTAMP is 2038-01-19 03:14:07. Hence the "special value" appears as 0000-00-00 00:00:00 in the database which will trigger the deletion when it is compared with the current date.
As a quickfix I changed the literal value in AuthToken.php to 2038-01-19 03:14:07.