Robotics StackExchange | Archived questions

Jenkins doc build fails because of nested custom messages which are hosted in external, unreleased package

Some of our indexed packages fail to be built on the Jenkins documentation server. The problem seems to be that those packages define custom messages/services/actions which have nested custom messages of our message repo (asr_msgs) and that repo can't be found during the build process.

You can find an example of a failed build here (for the package asrrecognizerprediction_ism). The other packages that fail share the same problem:

How can we fix this problem? Would it be sufficient to fully release the asrmsgs package so it will be available as a binary package and could be found by rosdep? Or is there some other way to provide the asrmsgs package to the documentation build process?

Asked by Tobi2001 on 2019-12-06 03:18:00 UTC

Comments

Suggestion: update the title to reflect the fact that these messages are hosted by packages that are unreleased.

"Nested custom messages" is probably not the problem.

Asked by gvdhoorn on 2019-12-06 07:03:21 UTC

Answers

I'm not entirely sure, but:

Would it be sufficient to fully release the asr_msgs package so it will be available as a binary package and could be found by rosdep?

yes, this would most likely solve the problem.

Or is there some other way to provide the asr_msgs package to the documentation build process?

There might be, at least according to this sentence in REP 141: ROS distribution files - distribution file (emphasis mine):

depends: list of repository names. Other repositories to perform cross referencing in the documentation. This is only necessary if the packages from the dependent repositories are not released. (default: [])

So a doc entry for a repository can have a depends key which lists the repositories the job would depend on. An example is shown in the same REP:

repositories:
  ...
  genmsg:
    doc:
      ...
    ...
  roscpp_core:
    doc:
      ...
      depends: [genmsg]

here roscpp_core's doc job would depend on genmsg.

There are a small number of doc jobs that use this, so it's likely this works (multiwii is an example: here, it depends onmsp. I'm not sure why it is configured that way, as msp appears to be released, but perhaps depends was used before it was released and never removed).

Asked by gvdhoorn on 2019-12-06 06:28:49 UTC

Comments