This rosdep install step can be one of the longest steps in the build process, especially for high level packages.
Completion Criteria
Changes to the workspace source that do not change the dependencies should not trigger a full rosdep reinstall. Ideally, only the build step should be run if possible. This will tighten the development iteration loop.
Implementation Notes
Potentially, can use a multi-stage Docker build
rosdep install --simulate outputs the installation commands that will be run, which can be dumped to a script
the sysroot creation step can run this script before taking the workspace sources - thus if a source change does not change the dependency list, the script will not change, and will not bust the cache
Testing Notes
Be aware that caching can break in subtle ways
Test pip-based rosdep dependencies
Test that changing a package.xml dependency busts the rosdep cache
The custom setup script / data directory can add rosdep rules, take this into account!
You could parse docker output for "used cache" to test whether this worked properly
Description
When iterating on a workspace, any change that I make to the source (https://github.com/ros-tooling/cross_compile/blob/master/cross_compile/Dockerfile_ros#L100) busts the docker cache, and causes a full
rosdep
reinstall (https://github.com/ros-tooling/cross_compile/blob/master/cross_compile/Dockerfile_ros#L108) even if the needed dependencies haven't changed.This rosdep install step can be one of the longest steps in the build process, especially for high level packages.
Completion Criteria
Implementation Notes
rosdep install --simulate
outputs the installation commands that will be run, which can be dumped to a scriptTesting Notes