Colcon in-container, an extension to build and test ROS 2 inside a container

Hello everyone,

Have you ever called rosdep on a ROS 2 package, only to realize that a dependency is missing when you try to build it? When developing a ROS 2 package or a ROS 2 workspace, one might rely on dependencies from the host not listed anywhere in the package.xml. This is creating inertia when deploying or distributing such packages due to missing dependencies.

At Canonical, we have been working on a colcon verb extension to run colcon commands inside a fresh and isolated ROS environment. With this extension, developers can build ROS packages for any ROS 2 distributions directly from colcon independently of the host. This allows you to separately validate builds and tests in isolated environments making sure all the dependencies are properly listed in the package.xml on any ROS 2 distribution.

Potential uses cases:

  • Build and test a ROS 2 package in a clean environment before releasing it
  • Build and test a ROS 2 package for a different ROS distribution
  • Make sure that your package.xml are up-to-date
  • Build and test a ROS 2 workspace with a ROS 2 version you haven’t installed
  • And more!

The project is available on GitHub at GitHub - canonical/colcon-in-container: Colcon extension to build a colcon workspace in a container alongside all the instructions to install and run it.

We are eager to collect some feedback from you ROS 2 developers. Please feel free to leave your feedback, comments as a message in this post or as an issue on GH. We’ll be monitoring and responding to your questions, so we can improve the tool based on your feedback. Your feedback is important to us!

For example, simply run colcon build-in-container --ros-distro humble to test if your package would build properly in a fresh 22.04 after installing just the dependencies from package.xml!

This extension is currently only supported on Linux. It is not intended to be used to start a container for development purposes.


I’ve faced this problem many times; great to see a tool to fix it.

How does this compare to using bloom, which I’ve used to catch similar errors?

@RFRIEDM What command of bloom are you referring to?
Bloom is used to prepare a release and doesn’t build itself.

As per this guide:

In the provided link, the package is built on the host via the debian/rules. This means that the dependencies of the host are going to be used.
The rosdep install command is not called.
In the case of a dependency already installed on the host and missing in the package.xml, no error will show.
With colcon in-container everything happens in an isolated environment, dependencies are pulled based on the package.xml and all of that with a single-command line.

An, great clarification. I’ll give your tool a whirl and see what it finds! Managing missing dependencies has always been easy to miss in code reviews…