tl;dr: Does anyone have experience with Docker containers who would like to setup some for MoveIt! ?
At our last MoveIt! maintainer meeting I brought up an issue with how difficult it is to test pull requests across different repos and different ROS distros. Maintainer @rhaschke suggested I try Docker containers, as he does, to prevent breaking my local workspace and work in development when testing someone else’s PR. I have been learning Docker the past couple months and have created two example MoveIt! images that build MoveIt! from source for both Jade and Kinetic but I think I could use some help and advice on how to go about this. Currently this Dockerfile for an experimental merged MoveIt! times out while being built automatically.
I would like to get a automated image of MoveIt! Indigo/Jade/Kinetic both built from source and perhaps installed from Debian. Does anyone want to lead this up for us? We could create a ros-planing/moveit_docker repo and model it off of ROS
Hey @davetcoleman ,
I worked on creating the Docker Hub repo for ROS, and would be willing to assist MoveIt! use it as well. Just trying out the Dockerfile you pointed to out locally on my system; seems to be taking it sweet old time during the rosdeb install. No surprise that Docker Hub may time out on it as a measure to prevent the build servers staling from ‘failing’ image builds.
I think your issue here is that your just missing environment variables, and calling commands from WORKDIR, or in this case /root/. Here is a real hacky fix I made it a few minutes just using the one Dockerfile, but I think you should break out parts of the build into executable scripts, use COPY to get them into the docker build container, then execute them with bash.
FROM ros:jade-ros-core
MAINTAINER Dave Coleman dave@dav.ee
# HACK, leaving old apt cache around for ros-deb
RUN apt-get update && apt-get install -y \
build-essential \
python-catkin-tools \
sudo
ENV CATKIN_WS=/root/catkin_ws
# HACK, bad practice
RUN rm /bin/sh \
&& ln -s /bin/bash /bin/sh
RUN source /ros_entrypoint.sh \
&& mkdir -p $CATKIN_WS/src \
&& cd $CATKIN_WS/src \
&& git clone https://github.com/davetcoleman/moveit.git
RUN source /ros_entrypoint.sh \
&& cd $CATKIN_WS/src/moveit \
&& rosdep install --verbose -y --from-paths . --ignore-src --rosdistro jade
RUN source /ros_entrypoint.sh \
&& cd $CATKIN_WS \
&& catkin build
RUN sed -i \
'/source "\/opt\/ros\/$ROS_DISTRO\/setup.bash"/a source "\$CATKIN_WS\/devel\/setup.bash"' \
/ros_entrypoint.sh
Just finished, with 8 cores and a modest internet connection:
$ time docker build -t=movit .
...
tput: No value for $TERM and no -T specified
Finished <<< moveit_setup_assistant [ 56.0 seconds ]
[build] Summary: All 22 packages succeeded!
[build] Ignored: 3 packages were skipped or are blacklisted.
[build] Warnings: 2 packages succeeded with warnings.
[build] Abandoned: No packages were abandoned.
[build] Failed: No packages failed.
[build] Runtime: 7 minutes and 40.2 seconds total.
[build] Note: Workspace packages have changed, please re-source setup files to use them.
---> 50ebe275d892
Removing intermediate container 31581ca5db61
Step 9 : RUN sed -i '/source "\/opt\/ros\/$ROS_DISTRO\/setup.bash"/a source "\$CATKIN_WS\/devel\/setup.bash"' /ros_entrypoint.sh
---> Running in 18aa1cf90c62
---> aba38f49ebb8
Removing intermediate container 18aa1cf90c62
Successfully built aba38f49ebb8
real 19m29.851s
user 0m1.124s
sys 0m0.728s
But I know the DockerHub buildfarm has 32 cores and a better bandwidth to the repo.
Some of the sources are unnecessary, It was just copy/pasta. I think the catkin call only requires it.
yes, I’ll send you a PR with a cleaner approach
I think it should, I’ve had longer builds before, one where I had to build stuff like PCL from scratch on DockerHub. Size becomes a factor there though. However the build above is only 1.932 GB.
Although I am still unsure how you would incorporate this with DockerHub for continuous integration, as that service is predominantly catered towards merely distribution, and thus may not be suited for testing. Still a fine meanes to share stable or beta releases of intermittent frequency.
@ruffsl I gave you commit access to moveit_docker in its temporary home. Feel free to skip PRs while we spin up the initial containers.
I don’t intend to use this for continuous integration, but rather to allow me to pull down a contributor’s PR and test it manually. Perhaps even for testing GUI changes, though that does not look easy with Docker
I talked with @tfoote, and from that I think I have a better understanding. You’d like to create and use a development image for MoveIt! that includes all the necessary build and test dependencies, then have that image serviced from an automated DockerHub repo, so maintainers and contributors could easlly pull the current base environment and build and test branches in question. Have I got that correct?
I can see how contributors could use this base dev image to build their PR locally and push the image of the PR to DockerHub to share with maintainers. I think that, if alone by itself, might require a fair bit of confidence that what is tested from the image that the maintainer pulls, is an exact build of the contributors PR, as any intermediate build and push steps might be chance for a misstep.
I had not thought of doing that, actually. I just want base MoveIt! images for each version of ROS that are ready for development, and each contributor can do whatever they like with it from there. One use case is testing PRs locally.
I’ve got the full* set of MoveIt! Docker images ready on Dockerhub - I’m pretty happy with their functionality. I’d like to invite everyone to review the Dockerfile build files, try the images out, and share feedback: