Docker Prebuilt and Devel Images Order

[isouf]

What is the rationale for building the prebuilt image prior to the devel image (link to code). The order has been reversed compared to how the Dockerfile was structured before the Docker container re-organisation (da22bdc).

[doganulus]

The meaning of devel container has been changed. Previously, devel was defined as a mere builder environment. Now the builder layer has been separated for the CI use, and the devel container now targets the end developer use. But this is an ongoing work, and what I would like to have is as follows:

1. base: Runtime base container
2. build: based on base Minimal container that can build Autoware and includes build dependencies
3. devel: based on build + visualization + extra dev tools
4. prebuilt: based on build + prebuilt binaries (this may not be needed)
5. runtime: base + prebuilt binaries + runtime dependencies

Having prebuilt binaries in devel may help reduce build times but let's see if it's worth it...

One big problem though is that ROS and Autoware packages do not declare their runtime dependencies with a strict discipline (even rclcpp does not have a runtime binary package). Therefore, the runtime container currently contains many development packages.

[isouf]

Thank you for the clear explanation @doganulus.

The main challenge with the present approach is that the devel container comes with a sourced ROS environment (it is sourced in the prebuilt stage). On the one hand this is nice as the user does not have to source /opt/ros/humble/setup.bash every time that gets in the container, on the other hand it limits the use of the container for applications that should not have a sourced ROS environment i.e. AWSIM+Autoware running inside the docker container tier4/AWSIM#81. I believe that your proposed structure base > build > devel > prebuilt > runtime would solved the above problem.

[doganulus]

The entrypoint script, which currently sources the ROS and Autoware environments, can be overridden by --entrypoint flag of docker run. This gives users a way to customize container start time. Yet I agree if you say, too many command line flags for common use cases is no good. So, the default option (sourcing or not sourcing) depends on the most common use case.

However, regarding simulators, I don't think Autoware and simulator in the same container is a good idea. Ideally, they would have their own standalone containers (AWSIM, SS2, and even Carla). Then, the user can write a compose.yml to run Autoware and the simulator together. This also helps the too-many-command-line-flag issue mentioned above. Stable Autoware interfaces and interface migration policies are essential to keep them all working.