3
$\begingroup$

I am working with ROS Noetic project in a team. Are there any existing techniques/tools for managing a freeze of the ROS rolling release? The intent is to achieve a more stable development and deployment environment. We use Docker for deployment and currently base our container on the robot image. We are on Ubuntu 20.04 LTS.

As of this writing, the newest ROS Noetic rolling release is noetic/2024-05-10: https://github.com/ros/rosdistro/tree/noetic/2024-05-10. In near future, there will likely be a new one (until EOL in May '25, but that's a different issue).

The problem with http://packages.ros.org is that this server seems to host only the very latest version of packages. Naturally, we could use http://snapshots.ros.org/noetic/ directly. However, it is my understanding that this service should not relied upon for production use.

Current manual approach (for noetic/2024-05-10):

  1. Make a copy of the necessary binary packages from http://snapshots.ros.org/noetic/2024-05-10 and host these privately.
  2. Create a fork of https://github.com/osrf/docker_images and patch necessary Dockerfile files. This allows us to build patched versions of the ros-core, ros-base, robot, and perception images that would target a specific rolling release.
  3. The patching for ros-core/Dockerfile would involve updating the deb line in /etc/apt/sources.list.d/ros1-latest.list so it uses the private server.
  4. The ros-base/Dockerfile seems to need a call to sed between rosdeb init and rosdep update. This call to sed would replace master with noetic/2024-05-10 in /etc/ros/rosdep/sources.list.d/20-default.list.

For development-machines, we would need to patch other things in a similar way.

Are there any other clever techniques for this that I've missed?

Improve this question
$\endgroup$
2
  • $\begingroup$ Have you considered mirroring the noetic apt repo and pointing all your devices and Dockerfiles to that? I would imagine that requiring the least amount of changes downstream. Of course, the idea would be to mirror only once and then stop the mirroring to freeze. $\endgroup$
    – Christian Fritz
    Commented Jun 1 at 16:11
  • 1
    $\begingroup$ @ChristianFritz Yes, I've considered doing that. The approach I describe in my question, is based on that exact idea. I was just wondering if there might be some standard techniques for maintaining this. But perhaps there are only special custom methods. $\endgroup$
    – O. Th. B.
    Commented Jun 2 at 10:15

1 Answer 1

Reset to default
1
$\begingroup$

One simple thing you can do is switching from Docker to Singularity/Apptainer. These are a bit different from Docker, but we've found them more useful for deployments on robots. The whole image is saved to a single file, so you can host the image file only and all robots/developers just download the right file and they're on track.

Improve this answer
$\endgroup$

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.