use distinct xunit pattern for ROS 2 #828
Conversation
Signed-off-by: Dirk Thomas <[email protected]>
dirk-thomas
deleted the
dirk-thomas/use-distinct-xunit-pattern-for-ros2
branch
|
I assume the current patch resolves the issue for Rolling and Foxy. For Eloquent (and likely Dashing) this needs more work: e.g. |
| types.append(('CTestType', 'ws/test_results/*/Testing/*/Test.xml')) | ||
| types.append(('GoogleTestType', 'ws/test_results/**/*.gtest.xml')) | ||
| types.append(( | ||
| 'JUnitType' if pytest_junit_compliant else 'GoogleTestType', |
There was a problem hiding this comment.
It's not super clear in the pytest documentation or in the deprecation warnings produced, but testing locally I've observed that using pytest version >= 6 does not imply that the junit_family type will be xunit2. In fact, if you don't explicitly set the junit_family (either with a pytest.ini file or a pytest -o option), then we get the legacy behavior. This is what's causing CI to fail for Foxy (ros2/ros2#1016).
I think this only happened to work for Rolling because of all of the backports explicitly setting the junit_family in pytest.ini files (ros2/ros2#951).
There was a problem hiding this comment.
See #836 for a proposed fix.
This redoes #723 and #724 (which were reverted in #725) and also adds a specific pattern for the xUnit type
CTestTypesince CTest result files are available now (see colcon/colcon-cmake#89).Without this change Jenkins tries to interpret the newly copied CTest result files as GoogleTest results files and chokes, e.g.:
With this patch:
I assume this works now because both buildfarms have been updated to the latest xUnit plugin version.