Universal_Robots_Client_Library
Universal_Robots_Client_Library copied to clipboard
UniversalRobots
Trigger the drivers integration tests
When introducing new changes to the client library, the changes applied could potentially make the drivers that are dependent on this library stop functioning properly. (ROS driver and Isaac driver)
To increase validation of the changes applied to this library, the build pipeline from the drivers could be triggered inside the build pipeline of this library or more specific trigger the integration tests from the drivers. This could decrease the possibility of introducing changes to the client library that would make the drivers stop functioning and to some extend ensure that the drivers are functioning with the new changes.
As of writing there is only one test in this library testing this library against a simulated robot which is the rtde_client test. This is also a motivation for triggering the drivers integration tests.
Seeing as industrial_ci is used here, this should not be that difficult to implement.
I believe it should be sufficient to specify the relevant packages for a build in a downstream workspace. industrial_ci then takes care of everything else.
The detailed documentation has a few sections which go into some detail.
@ipa-mdl?
Added downstream tests for ROS driver. @urmahp you will add something for the ISAAC driver?
Unfortunately, it's probably not going to be that easy as this is not a catkin package where the tests get run by the industrial_ci pipeline automatically.
Added downstream tests for ROS driver. @urmahp you will add something for the ISAAC driver?
Unfortunately, it's probably not going to be that easy as this is not a catkin package where the tests get run by the industrial_ci pipeline automatically.
Yes I also think it is going to be a bit more difficult to add something for the ISAAC driver, but once I have the pipeline running in the ISAAC driver I will look at implementing something for it.
As a short-cut you could add a manifest to the directory containing the main CMakeLists.txt.
It would still not make it a "Catkin package", but with build_type set to cmake, both Colcon and catkin_tools can build such packages, and so should industrial_ci.
As a short-cut you could add a manifest to the directory containing the main
CMakeLists.txt.It would still not make it a "Catkin package", but with
build_typeset tocmake, both Colcon andcatkin_toolscan build such packages, and so shouldindustrial_ci.
This would be only a build check, right? As tests are not defined in a catkin way, they won't be run.
I'm sort-of expecting tests to be run as well, as in the end, it's just a target in a Makefile, but I'm not sure about it.
Would be worth a try.
At least for this repo, tests aren't run, which is why I have setup a second workflow running the tests, which only calls make test.
Ok.
Well, it's possible to run custom commands as part of the pipeline, so running make test yourself should be possible.
See tesseract/.github/workflows/bionic_build.yml fi.
None of the tesseract packages are Catkin packages. They're not even "ROS packages" (whatever that means) in that repository.
(I'm of course not saying you should absolutely use industrial_ci, just wanted to mention the possibility)
As tests are not defined in a catkin way, they won't be run.
colcon runs CTest as well..
It also seem that GitHub action can trigger action in other repos http://blog.marcnuri.com/triggering-github-actions-across-different-repositories/
