Proposal: defer GitHub Actions publish until a platform build completes

[han-xudong]

Hi, while looking into partial-update dependency conflicts in downstream RoboStack channels, I wondered whether generated GitHub Actions workflows may be publishing a platform too early.

From what I can tell, packages can currently be uploaded while only part of a platform's dependency graph has finished building. For large ROS distributions, that seems likely to expose a partially updated platform state for some period of time.

Would you be open to an optional generator-level mode that defers upload until the full platform build has completed successfully?

A possible approach would be:

• keep the current behavior as the default
• add an opt-in mode such as platform-finalize
• in that mode, batch jobs only build and upload workflow artifacts
• add a final per-platform publish job that downloads those artifacts and uploads them only after the required build jobs succeed

I have a local prototype in progress that follows this pattern, and it seems compatible with GitHub Actions' documented needs and artifact flow. If this is the wrong layer or there is already a preferred mechanism, I would appreciate the correction.

[Tobias-Fischer]

Is this related to RoboStack/robostack.github.io#139? Again, if we could dig down as to what the exact issue is, that'd be great.

[han-xudong]

@Tobias-Fischer Yes, this is directly related to RoboStack/robostack.github.io#139, and a concrete example is intrinsic-dev/aic#463.

In that issue, pixi install failed on linux-64, and the analysis pointed to a temporary inconsistency in published robostack-kilted package metadata during a kilted update. At the time, some packages on that platform were still requiring ros2-distro-mutex 0.13.*, while others had already moved to 0.14.*.

For example, I observed combinations like:

• ros-kilted-lifecycle / ros-kilted-ros-core still on 0.13.*
• ros-kilted-ament-cmake / ros-kilted-rosidl-default-generators already on 0.14.*

So the downstream symptom was a real solver failure, but the thing I am pointing at here in vinca is the upstream mechanism that can make that kind of temporary partial-platform publication possible.

That is why I proposed an optional generator-level mode here:

• keep the current behavior as the default
• allow an opt-in mode where build batches can still run independently
• but defer publication until the full platform build has succeeded

So my intent is:

• ros-kilted#68 describes the downstream release-process problem
• this vinca issue is about whether the generator should support a publish model that avoids exposing that intermediate state in the first place