@ruffsl I'm interested in using this, is there any action item that I can help with?

Context: I would like to use this as a base for CI pending dashing packages being available.
In order to avoid duplicating dependency listing in multiple repos, I'm wondering if we could have an image built with all the building and testing tools as well (such as colcon, vcstool, flake8 plugins etc). Could this be integrated in the nightly images from this template? or would a separate image be preferred?

@ruffsl I'm interested in using this, is there any action item that I can help with?

I think this template is currently a little out of sync w.r.t the ros2 nightly Dockerfile. I can't remember what hanged me up, but I think it was when I was still trying to narrow down what keys I needed to skip here:

https://github.com/osrf/docker_images/blob/cb0ce5bef267d8c305f6cfd2ded846c9444c4fc7/ros2/nightly/nightly/Dockerfile#L63-L72

Feel free to tack on more commits to this branch.

I'm wondering if we could have an image built with all the building and testing tools as well (such as colcon, vcstool, pyflakes plugins etc). Could this be integrated in the nightly images frim this template? or would a separate image be preferred?

I was also thinking of adding a osrf/ros2:devel image for just that purpose: ros-navigation/navigation2#606 (comment)

I think this template is currently a little out of sync w.r.t the ros2 nightly Dockerfile. I can't remember what hanged me up, but I think it was when I was still trying to narrow down what keys I needed to skip here:

Looks like the main differences between the Dockerfile and the template are:

• placeholder/prereqs rosdep keys
• sed logic to replace colcon prefix
• list of skipped keys

I was also thinking of adding a osrf/ros2:devel image for just that purpose: ros-navigation/navigation2#606 (comment)

It looks like there are 2 different images suggested (both including the tools defined below):

• an image with no ROS package installed but with some tools installed
• an image with the nightly artifacts ready to use + tools

Are we ok hosting both these images?
How would we like to name them?

"tools" / what will be common to both images:

• the ros2 apt repos added to the sources
• rosdep package installed and initialized
• the tools to import repos files (vcstool)
• tools for building (colcon)
• tools for testing (pip dependencies used for testing)

an image with the nightly artifacts ready to use + tools
Are we ok hosting both these images?

The nightly image that was introduced in osrf/docker_images#202 and is being used by navigation2 and movit2 to accelerate their CI jobs when tracking nightly changes.

https://hub.docker.com/r/osrf/ros2/tags

an image with no ROS package installed but with some tools installed
How would we like to name them?

I thought it might be useful, just to have a development image primed for build latest ROS2 packages from source, without necessarily preloading it with any released or nightly package. I'm not sure what we should call it, osrf/ros2:devel seemed like an ok fit.

"tools" / what will be common to both images:

It could literally be the exact same, only with these two lines omitted, and still build:

RUN wget https://raw.githubusercontent.com/ros2/ros2/release-latest/ros2.repos \
    && vcs import src < ros2.repos

https://github.com/osrf/docker_images/blob/086440f267921cf4ff39e90bb8e07c81e243dddc/ros2/source/source/Dockerfile#L64-L65

This could help give consumers a cositent entrypoint and workspace setup to clone code into.

The nightly image that was introduced in osrf/docker_images#202 and is being used by navigation2 and movit2 to accelerate their CI jobs when tracking nightly changes.

Yes, my original request was for that image to also include the bootstrap and testing packages to have an image ready to build and test workspaces.
I opened #52 regarding the bootstrap packages (does not include the testing dependencies from pip).

I thought it might be useful, just to have a development image primed for build latest ROS2 packages from source, without necessarily preloading it with any released or nightly package. I'm not sure what we should call it, osrf/ros2:devel seemed like an ok fit.

It could literally be the exact same, only with these two lines omitted, and still build:
This could help give consumers a cositent entrypoint and workspace setup to clone code into.

To clarify my understanding, are you recommending the ros2:devel image to have an empty workspace, or a workspace with the latest ROS 2 packages cloned?

To clarify my understanding, are you recommending the ros2:devel image to have an empty workspace, or a workspace with the latest ROS 2 packages cloned?

An empty but build workspace (nothing cloned into /src). The empty workspace still needs to be built using colcon build if we are to reuse the exact same entrypoint that sources /install/setup.bash.

After some experimentation, I have a version available here, that integrates the changes to the nightly template and the addition ros2:devel image (corresponding docker_images branch)

2 points to decide still regarding the nightly template:

• where to place the custom rosdep rules logic: template it and pass the custom yaml file name as an argument?
• what to do regarding the sed statements: currently being discussed at [ros2/nightly] narrowing down skipped rosdep keys docker_images#245

PRs have been opened:
adding devel image: #57 + osrf/docker_images#246
changes to nightly template: #55 + osrf/docker_images#245 + osrf/docker_images#247

Continuing with #55