search

canonical / colcon-in-container

Colcon extension to build a colcon workspace in a container
GNU General Public License v3.0
25 stars 1 forks source link

Allow colcon release-in-container to use more that 1 cpu #24

Open aosmw opened 2 months ago

aosmw commented 2 months ago

I noticed that the colcon release-in-container does a build that only uses 1 cpu.

Here is a related discussion that bloom is that way in order to make it work for the ros build farm use case. https://github.com/ros-infrastructure/bloom/pull/643

Guillaumebeuzeboc commented 2 months ago

Thanks for the feedback and the link. In the case of the release-in-container we are building the packages in a deterministic order, so that shouldn't cause any issue. Now I am more wondering if we should and how to integrate such a change in release-in-container.

I would probably be simpler if Bloom could get released with that change, since the project is not meant to diverge from upstream.

aosmw commented 2 months ago

The change, IF you decided to do it, could be allow debian/compat to be overwritten to a number (10 or even 13). other than what it currently defaults to after the bloom-generate call, https://github.com/canonical/colcon-in-container/blob/33551d2e76adb4a1c900198c7e6114fcf576dc48/colcon_in_container/verb/release_in_container.py#L92

Here is a script where it is done with a simple echo 11 > debian/compat which is a comment in https://github.com/ros-industrial/industrial_ci/issues/697#issuecomment-876293987

Turns out that 11 is not recommended. 10 would be enough to satisfy this issue. Automatically do the build in parallel.

artivis commented 2 months ago

I agree that I would prefer this to land in bloom rather than as a workaround here.

Linking the related bloom ticket: https://github.com/ros-infrastructure/bloom/pull/643.