Build failed in Jenkins: sensor_msgs/NavSatFix.h: No such file or directory

Question

Hi there, I released a new ROS package. But, the Jenkins job failed with following error:

/tmp/binarydeb/ros-kinetic-dgps-ros-1.0.0/src/dgps_ros_node.cpp:2:35: fatal error: sensor_msgs/NavSatFix.h: No such file or directory compilation terminated.

I checked my package.xml and found the sensor_msgs dependency is missing, so I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

But, the Jenkins job still failed with the same error.

---

Originally posted by qinyunchuan on ROS Answers with karma: 3 on 2021-01-17

Post score: 0

---

Original comments

Comment by gvdhoorn on 2021-01-17:
Your repository appears to be hosted on gitee. That's annoying, as it's impossible to do anything there without an account.

Comment by qinyunchuan on 2021-01-17:
I have changed the upstream repository to github with a new PR.

Answer 1

I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

you cannot do this.

It's both not how tags are supposed to work, and doesn't solve the problem you're seeing.

But, the Jenkins job still failed with the same error.

The reason is that the buildfarm does not clone your source repository when it runs a binary job. Nor do source jobs.

Bloom commits the tagged version from your source repository to your release repository and that repository is then fetched by the various jobs on the buildfarm. They only run though when they notice you've (re)released your package. To figure out whether you've done that, the relevant distribution.yaml is checked (for a newer version number).

Right now, if the buildfarm needs to rebuild your package (because of a release of one of your dependencies for instance), it will fetch your current released version from your release repository (which still has the problem) and nothing will change.

The only proper way to fix the dependency issue is to release your package again.

Suggested steps:

1. revert your changes to your 1.0.0 tag: let it point to whatever commit is was pointing to before you changed it. You should not change tags like that in any case
2. follow the Releasing a new version of a catkin package tutorial. So (but make sure to follow the tutorial):
3. update your changelog
4. create a new tag
5. run Bloom

After you submit the PR and it gets accepted, the source job will fetch your new version (with the fix) and the binary jobs will start building your new version.

---

Originally posted by gvdhoorn with karma: 86574 on 2021-01-17

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by qinyunchuan on 2021-01-17:
Thanks for your reply. Thank you very much. But I am still a little confused. Why the Jenkins job runs everyday with the same error, with same code. And the we could do nothing except waiting for the PR to be acceped?

Comment by gvdhoorn on 2021-01-17:
It would help if you could link to your Jenkins jobs. Right now we're just guessing.