At which phase of a build should haros be run?

[gavanderhoorn]

This connects to #13.

Right now we either run haros always (by adding it to "the default build target", typically all for Makefiles) or as part of run_tests (or at least: I have that working in my local version).

As haros itself only outputs a report, I'm not sure what would be the best phase of a typical build it should integrated with.

[gavanderhoorn]

We might want to see how rosdoc documentation is part of a build.

It could be it's not and you need to invoke the build of that manually, but it could also be added to another target. I don't remember, it's been a while since I last looked at that.

This ticket is more about the idea of running haros as an inspection tool.

Perhaps looking at which stage the ROS 2 linters are run could provide some inspiration.

[gavanderhoorn]

@git-afsantos: would you have any input?

[gavanderhoorn]

Also connected to #11.

[git-afsantos]

Both suggestions work, and it really depends on the workflow. Since haros is being used only as a static analyser, it could (should?) be run with every build (as a compiler would). On the other hand, sometimes the changes from one build to another are small, and people would be more interested in these results "on demand" or "when it makes sense", like tests.

In this specific context, I think the main questions are

1. does the phase it runs in make a difference for the build farm (performance, load, etc.); and
2. how immediate is this feedback for the end users in one phase versus the other?

[nlimpert]

Perhaps looking at which stage the ROS 2 linters are run could provide some inspiration.

I found this entry on ROS Answers in which Dirk Thomas states the following:
"[...] in ROS 2 any kind of linters are integrated on a per-package level. So when you run the tests of a package you also run any kind of linter available [...]".

So I guess it's a good idea to adhere to this procedure and do the same for haros_catkin and integrate it as part of run_tests ?

[gavanderhoorn]

Hm, that is a nice find.

I've not looked at how those linters are integrated. Would you know?

[nlimpert]

I've not looked at how those linters are integrated. Would you know?

No not yet. This seems to be a nice introduction which looks like it boils down to:

1. Create a ROS package to contain the linter including setup.py and the appropriate python script to execute the linter and return an appropriate value. This can for example also be an invocation of clang-format - see here).
   To adhere to Jenkins' ability to parse output the script has to generate JUnit XML output (this is probably of interest in terms of @max-krichenbauer's suggestion to display HAROS output on the ROS Wiki as well as on Jenkins.

2. Create another package that contains the appropriate CMake macros to invoke the script created in 1.

3. The package created in 2. has to define a set of dependencies in its package.xml to adhere to ament's registration for test setups. It also needs the CMake Configuration to invoke ament_copyright() and ament_lint_cmake(). This package also has to provide a CMake macro to invoke the CMake macro created in 1.

4. The actual CMake macro that invokes the newly introduced linter looks like this.

So the overall procedure generally seems to take two packages - one for the actual linter process (being a CLI wrapper) and another one to contain the CMake scripts to register the linter to run during tests.