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
Run QoS tests. #441
Run QoS tests. #441
Conversation
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Several tests fail on |
One suggestion; enable the tests that actually pass right now, then do a follow-up issue/PR to fix and enable the ones that don't. That way we at least will get some of the test coverage here. |
Do you happen to have a link to the failures? |
@dabonnie I've only reproduced locally. Here's a CI run for reference: I wonder why there's no Rolling PR job though. @nuclearsandwich ? |
The job is not enabled in the rosdistro distribution.yaml. I'm not sure if it can be enabled without a binary job though. |
I think it's worthwhile to run / test via actions-ros-ci: I'll be adding an issue / PR. |
A repository can have dev and PR jobs if all its dependencies are released. It doesn't have to be release itself.
For these repositories please continue due use the Jenkins-based PR / CI builds since they provide a lot of benefits over the in-development actions atm. |
Can't we do both? What's the downside to having scheduled actions running at a 1h or 1day interval exposing these kinds of issues? It may be that I'm not aware that adding a job on Jenkins is a fairly easy task, so in that case I would agree we only need your approach. |
Sure, we can have both. But not only actions since the Jenkins based jobs provide more functionality. So please also enable pull request jobs for this repository. |
The Jenkins jobs in build.ros.org and build.ros2.org are fully automated. All it takes is seeing the key |
PR to enable pull request testing for Rolling on build.ros2.org ros/rosdistro#25806 |
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Alright, based on ros2/rmw_fastrtps#384 (comment) I believe I got the tests right. @dabonnie PTAL. |
@@ -30,57 +30,13 @@ | |||
|
|||
using namespace std::chrono_literals; | |||
|
|||
///// Test Deadline with a single subscriber node | |||
TEST_F(QosRclcppTestFixture, test_deadline_no_publisher) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why this test was removed, as it checks for spurious events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on its current definition, deadline QoS establishes the maximum inter-arrival time for messages. If no message is ever published, no deadline event will be received. It is a bit counter-intuitive, but that's how it is for DDS and ROS.
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
To cope with longer discovery times. Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
To cope with longer discovery times. Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Ready for another look, PTAL! I had to tweak the lifespan test a bit and increase timeouts and period for |
@@ -33,7 +33,8 @@ using namespace std::chrono_literals; | |||
/// Test Deadline with a single publishing node and single subscriber node | |||
TEST_F(QosRclcppTestFixture, test_deadline) { | |||
int expected_number_of_events = 4; | |||
const std::chrono::milliseconds deadline_duration = 1s; | |||
const std::chrono::milliseconds deadline_duration = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: an explanation why this is different for connext (observed via CI, your testing, etc)
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
I'm starting to wonder if it's even possible to write a QoS test like these that's not intrinsically flaky. |
The last few failing tests on Windows are due to Fast-RTPS hanging on subscription destruction. @richiprosima @MiguelCompany I've tracked it down to |
@richiprosima @MiguelCompany friendly ping. Would a backtrace help you guys? |
@EduPonz @MiguelCompany ping |
Sorry @hidmic , this flew completely under our radar. Some backtrace would indeed be most welcomed. Also, anything you think worth mentioning for replicating would be much appreciated. We did some refactoring on the Thanks! |
@ros-pull-request-builder retest this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me and has green CI.
Alright, let's get this in. Thanks @clalancette ! |
As a result of the investigation for ros2/rmw_fastrtps#384, it was apparent that
test_quality_of_service
tests were actually not being run. This patch corrects the situation.