feat: dependency version pinning for reproducible builds

[youtalk]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Introduce lock file-based dependency version pinning for both native and Docker setups to ensure reproducible builds. Currently, ROS APT packages, system APT packages, Python packages, Docker base images, and ROS 2 APT source versions are resolved dynamically at build time, making builds non-reproducible across different dates.

The approach adds an opt-in --locked flag to setup-dev-env.sh (and USE_LOCKFILE=true build arg for Docker) that loads pre-generated lock files containing exact package versions. Default behavior remains unchanged.

Design proposal: https://github.com/orgs/autowarefoundation/discussions/6861

Purpose

• Enable reproducible release builds: same commit always produces the same build environment
• Support reliable release management and regression debugging
• Maintain developer flexibility (latest packages by default, locked versions opt-in)

Possible approaches

See the design proposal for the full comparison. The selected approach is lock file method for both native (Ansible lock files) and Docker (lock files + base image digest pinning), chosen for its low implementation/operational cost and high compatibility with existing infrastructure.

Definition of done

• Phase 1: Add --locked option to setup-dev-env.sh, create lock file generation/validation scripts, and generate initial template lock files
• Phase 2: Modify all Ansible roles to conditionally install locked versions when use_locked_versions is set, with snapshots.ros.org support for ROS packages
• Phase 3: Add USE_LOCKFILE support to Dockerfiles, pin base image digests, and add --locked flag to docker/build.sh
• Phase 4: Create lock file generation workflow (monthly + manual) and validation workflow (on PR)

[paulsohn]

Maybe we can consider Pixi before deciding to reinvent the wheel. cc @mojomex

[mojomex]

@youtalk Thank you for the initiative. I'm very happy to see that something akin to my TIER IV INTERNAL proposals from some while ago is now starting to gain traction. I think not having locked dependencies is the single biggest pain point of Autoware right now.

I agree with @paulsohn though, that Pixi, the multi-language package manager that is starting to gain traction in official ROS 2, is the way to go. It relies on the battle-proven Conda ecosystem and uv package manager, making the tool blazing fast, OS-agnostic and robust.

[youtalk]

@paulsohn @mojomex I believe Pixi is a very good option. However, since the gap between Pixi and our current build system is quite large, a simple migration isn't feasible at this time.
My proposal is to first focus on achieving version pinning, which can be realized with minimal incremental development.
How about we move forward with the Pixi migration as the next step after that?

[mojomex]

@youtalk Thank you for the insight. I understand your sentiment - the Robostack ecosystem is powerful, but lagging behind Rosdistro and will add maintenance overhead. And Pixi-Build-ROS is still in preview, making it a non-starter for now.

But it's good to hear that it is being considered as a future option, and I'm excited for when that future arrives!

[paulsohn]

@youtalk Can you share the detail on what particular gaps you are thinking, so we can have more productive discussion on how to fill them?

I am considering:

• install ROS buildfarm dependencies with pixi, so we can skip rosdep
• keep vcs clone and colcon build, just inside pixi shell

I agree that we still have lots to investigate e.g. caching and deployment process, but if we are eventually planning for pixi it is always better to verbalize everything in advance.