0
$\begingroup$

Rosanswers logo

Hey Forum

I'm working on submitting a sensor driver package to bloom for the first time. My package (https://github.com/ifm/ifm3d-ros) has unit tests which require the presence of my sensor hardware to execute. The tests are currently optional under the CATKIN_ENABLE_TESTING flag.

My suspicion is that bloom will automatically run these tests (and thus fail due to no hardware), correct? If so, I suppose I need to either:

  1. Wrap the testing clause inside another opt-in custom CMAKE flag which won't be set inside of the bloom system
  2. Identify some other bloom mechanism to explicitly opt-out of testing for my package

Is one or the other option preferred?

Thanks!


Originally posted by theseankelly on ROS Answers with karma: 23 on 2020-03-05

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

My suspicion is that bloom will automatically run these tests (and thus fail due to no hardware), correct?

No, not really.

This could be me being pedantic, but Bloom does not run any tests. Its "only" responsibility is to create source archives of your packages and upload those (+ some metadata) to your release repository (it does a few more things of course).

The buildfarm will then use those source archives and will run jobs that will -- in the end -- create .deb and .rpm (depending on how its configured).

Afaik the release jobs do not actually run any tests The tests are run in release jobs, but the results of the tests do not influence the success of a release build (thanks @nuclearsandwich ). That would be the responsibility of the devel jobs.

Assuming this is your package (or one of them), the devel jobs appear to have been failing so far, but not because of the tests.


Originally posted by gvdhoorn with karma: 86574 on 2020-03-05

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by theseankelly on 2020-03-05:
That was my original understanding, but then I ran a bloom Prerelease Test for the core driver package (ifm3d_core) on which this ROS package (ifm3d) depends, it included the ifm3d dependency and ran tests, which failed.

Comment by gvdhoorn on 2020-03-05:
A prerelease test is not part of Bloom. The process is just documented there as it's good to do one as part of the release cycle. Bloom is not involved.

The command you run is executed in a docker container on your local machine. If that container doesn't have access to the required hw, the tests will fail -- as expected.

Again, IIRC, the release jobs do not run the tests.

Comment by nuclearsandwich on 2020-03-05:
@gvdhoorn is correct that bloom itself won't run tests. It does generate RPM and debian package metadata for building your packages (which will be performed on the ROS build farms for officially released packages). As part of the package build process, tests are run but the results are discarded and the package is packaged regardless of test status.

You can see how this is implemented in the template for a debian/rules Makefile for building an ament_cmake package: https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/templates/ament_cmake/rules.em#L46

The devel / pr jobs do run and process tests and if those tests rely on hardware to be available then they can likely never pass on our build farm. Making the tests off by default or only running them if the required hardware is available are both ways I can think of to make the tests work on the official build farm.

Comment by theseankelly on 2020-03-05:
Thanks @gvdhoorn and @nuclearsandwich.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.