search

ros-infrastructure / ros_buildfarm

ROS buildfarm based on Docker
Apache License 2.0
81 stars 96 forks source link

Stop implicitly installing the ros_workspace package #950

Closed cottsay closed 2 years ago

cottsay commented 2 years ago

This will only affect ROS 2 builds.

At some point, it was necessary for CI and/or Devel jobs to unconditionally install the ros_workspace package. There are some recent developments and goals which would benefit from discontinuing this practice and letting the debians install the workspace as a dependency only when called for.

This is an exploratory PR to see what classes of jobs will fall over outright without this behavior. If things look okay, I'll try to come up with some more contrived cases to break things.

cottsay commented 2 years ago

I'm not sure if the following code under release script is related (injecting ros_workspace somehow?) but we anyway probably want to explore the failings jobs before removing that from releasing (if related).

That takes care of ensuring that the Jenkins release jobs are aware of the implicit dependency - this change deals specifically with the Devel and CI jobs. I don't see a path where we would remove the referenced code.

I think that only scenario where this would break behavior is for devel jobs for a cmake (as opposed to ament_cmake) build type package which has implicit dependencies on packages inside the ROS FHS and thus would be unable to find them. But any package with its dependencies properly expressed should get ros_workspace pulled in transitively so let 'em rip I say!

Any repository which contains packages which depend on ament_package and/or ament_cmake_core and no other ROS packages could be broken by this change, but I'm not aware of any repositories which meet that criteria.