Add a pixi toml url to the build parameter arguments

[knmcguire]

Description

Currently the location of the pixi.toml file is a bit hardcoded. See

ci/windows_docker_resources/Dockerfile

Line 53 in 15f43e0

RUN powershell -noexit irm https://raw.githubusercontent.com/ros2/ros2/refs/heads/%ROS_DISTRO%/pixi.toml -OutFile pixi.toml

This PR adds a CI_PIXI_TOML_URL parameter that will add an option to add an custom pixi.toml url (like in a gist). This allows us to test PRs like this one: ros2/ros2#1785 (this adds a version change to pixi.toml), and we would able to debug dependency issues without having to make a branch on the main ros2/CI repository for windows.

This is related to issue #832

Is this user-facing behavior change?

Yes, on ci.ros.org users can now see an new parameter called CI_PIXI_TOML_URL that they can fill in with another url as similar fasion as with CI_ROS2_REPOS_URL. But nothing should happen if they don't fill it in.

Did you use Generative AI?

Yes, only for one commit: 2ff6534

this was done with Claude Code (Opus 4.5)

Additional Information

I'll leave it in draft as I just want to double check things before merging (or have people look at it at least to see if I'm not breaking the whole CI!)

[claraberendsen]

The changes LGTM!
Thanks for setting this up this will make it much easier to roll Windows dependencies 🎉 .
We can monopolize test_ci_windows momentarily and deploy these changes there to validate that they work as expected.

[ros-discourse]

This pull request has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.openrobotics.org/t/ros-pmc-minutes-for-january-20-2026/52015/1

[cottsay]

It looks like the "original" behavior determined the URL dynamically by substituting the ROS distro.

When we trigger a job for a distribution other than Rolling, there's currently a bunch of job parameters that we need to change. Would it be possible to make the default value for this parameter empty, which will produce the existing behavior?

There are certainly other parameters that should behave like this but don't, and it would be great to set a better precedent moving forward.

[knmcguire]

@cottsay thanks! I've address your comments but since I had to port this branch to this repo I had to make a new PR. All the commits except for the last are the same.

#841