Remove the pytest.ini workaround for distros after Foxy.#497
Remove the pytest.ini workaround for distros after Foxy.#497clalancette merged 2 commits intomasterfrom
Conversation
After Foxy was released, we added pytest.ini to all of the packages that required it. This was so that local tests behaved the same as CI. In Foxy and prior, we still need the workaround so CI will succeed. Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
|
CI with distro set to Rolling: Both are expected to succeed, but the Foxy one should have some extra output at the beginning of the test section that says: While the rolling one should not. |
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
+1 although I keep the warning I wrote here #471 (comment) |
|
Rolling CI failed because we are still on a version before my fix: https://gitlab.com/micro-ROS/ros_tracing/ros2_tracing/-/merge_requests/185 . I'll talk to the ros2_tracing people and see if we can get an update. https://gitlab.com/micro-ROS/ros_tracing/ros2_tracing/-/issues/98 |
|
ros2_tracing is now on master, so we can try again. Here's another CI run: CI with distro set to Rolling: |
Right, it is definitely still the case that if any package is added that doesn't have the proper pytest.ini, it will cause the build to fail. While that isn't exactly nice, the good news is that it is very noisy and it should be obvious why it failed. So I still think we should go forward with this. I'm going to go ahead and do a full CI run on all platforms just to make sure there aren't any surprises with Rolling. After that, I'll probably go ahead and merge unless @j-rivero has any other concerns with this PR. |
|
Full CI:
|
3 participants
After Foxy was released, we added pytest.ini to all of the
packages that required it. This was so that local tests behaved
the same as CI. In Foxy and prior, we still need the workaround
so CI will succeed.
Signed-off-by: Chris Lalancette clalancette@openrobotics.org
Still in draft since I need to run tests on it. @j-rivero FYI, this relates to (but does not completely remove the need for) #471. This also relates to ros2/ros2#951