[Tobias-Fischer]

The staged GitHub Actions workflow cuts each stage into jobs of --batch_size recipes in list order. The heavy recipes of a stage often end up in one job, which then holds up the whole stage.

In RoboStack's jazzy full rebuild, a single job was running alone for 55% of the wall time on Linux. For example, rviz_default_plugins and nav2_behavior_tree shared a 25-minute job, while the other jobs of that stage took about 3 minutes.

vinca-gha --timings <file> [--runners N] (opt-in; without --timings nothing changes):

• Input: the file holds {"recipes": {name: seconds}, "default": seconds, "job_overhead": seconds}.
• Packing: each stage is packed longest-first into the number of jobs that gives the shortest stage on N runners. N defaults to GitHub's limit on concurrent jobs with its hosted runners, 20 or 5 on macOS (the Free plan). It uses fewer jobs when that costs at most 1%. No job gets more than --batch_size recipes, and each job keeps the stage's order.
• Short stages: consecutive stages of at most 2 minutes still share one job, in order.
• Compatibility packages: with package_name_mode: both, each ros-<distro>-<name> package only depends on ros2-<name> (and the mutex, which that needs too). It is now built right after that package in the same job, and its time counts towards it, instead of a stage later in another job. One whose ros2- package isn't being built stays where it is (batch_stages(..., followers=...)).
• Stages stay sequential, so the dependency order doesn't change.

vinca-gha --keep-file <path>: every build job (unix, macOS, Windows) ends with an upload-artifact step for that file, named after the job, also when the build failed. RoboStack uses it to keep the build times its jobs record, which become the --timings input.

Checked against the real jazzy rebuild (linux-64, 2405 recipes, per-recipe times from its logs, simulated with 8 runners):

	stages	jobs	wall	runner time	workflow
by count (today)	48	117	6.96 h (the run took 6.93 h)	12.0 h	292 KiB
--timings --runners 8	52	233	2.68 h	12.2 h	384 KiB
--timings (20 runners)		283	2.47 h (3.00 h if only 8 are free)		442 KiB

• Correctness: every recipe's ROS dependencies are in an earlier stage or earlier in its job, and every compatibility package comes right after its package.
• Fewer free runners: if only 5 are free instead of the planned 8, wall time is 3.71 h. Pass --runners when fewer can be counted on, e.g. when several workflows share the account's limit.
• Tests: 11 new tests for time packing, the batch-size cap, shared short stages, followers, BuildTimings.from_file, compatibility_followers and --keep-file. All 305 pass, and ruff is clean.

RoboStack/robostack#139 records the times in its build jobs, keeps them with --keep-file, and passes them back as --timings, averaged over its distributions.

The measurements and the comparison with #149's scheduler are in the analysis behind this; in short, plain time-balancing within the existing stages captures most of the gain.

🤖 Claude (AI assistant), on behalf of @Tobias-Fischer

🤖 Generated with Claude Code

[Tobias-Fischer]

@baszalmstra - what do you think of this approach? Meant to replace / complement #149.

@traversaro - do you mind having a look as well?

RoboStack PR to save the timings in the first instance and then use the new functionality: RoboStack/robostack#139

[baszalmstra]

this looks like a much better approach than what I tried!

[traversaro]

Great! How do we plan to maintain the timings file? Every full rebuild overwrites the timing file check in in the repo?

[traversaro]

Great! How do we plan to maintain the timings file? Every full rebuild overwrites the timing file check in in the repo?

Never-ending, I now saw the corresponding robostack PR!