Ask Your Question
0

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

asked 2019-12-06 02:18:00 -0600

Tobi2001 gravatar image

updated 2019-12-06 07:00:04 -0600

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 asr_recognizer_prediction_ism). The other packages that fail share the same problem:

  • asr_direct_search_manager
  • asr_next_best_view
  • asr_recognizer_prediction_psm
  • asr_world_model

How can we fix this problem? 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? Or is there some other way to provide the asr_msgs package to the documentation build process?

edit retag flag offensive close merge delete

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.

gvdhoorn gravatar imagegvdhoorn ( 2019-12-06 06:03:21 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2019-12-06 05:28:49 -0600

gvdhoorn gravatar image

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).

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-12-06 02:18:00 -0600

Seen: 26 times

Last updated: Dec 06 '19