Repository navigation
Post-PR failures September 2026 #48
Description
ros-lyrical-ur-simulation-gz
ros-lyrical-ur
ros-lyrical-moveit
Traceback (most recent call last):
File "/home/runner/work/ros-lyrical/ros-lyrical/.pixi/envs/default/bin/vinca-gha", line 10, in <module>
sys.exit(main())
~~~~^^
File "/home/runner/work/ros-lyrical/ros-lyrical/.pixi/envs/default/lib/python3.14/site-packages/vinca/generate_gha.py", line 589, in main
build_unix_pipeline(
~~~~~~~~~~~~~~~~~~~^
stages,
^^^^^^^
...<6 lines>...
pixi_version=pixi_version,
^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/home/runner/work/ros-lyrical/ros-lyrical/.pixi/envs/default/lib/python3.14/site-packages/vinca/generate_gha.py", line 280, in build_unix_pipeline
dump_for_gha(workflow, outfile)
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/ros-lyrical/ros-lyrical/.pixi/envs/default/lib/python3.14/site-packages/vinca/generate_gha.py", line 160, in dump_for_gha
raise RuntimeError(
...<3 lines>...
)
RuntimeError: Generated workflow linux_aarch64.yml is 504.7 KiB, exceeding the 500 KiB limit. Increase --batch_size to reduce the number of generated jobs.
https://github.com/RoboStack/ros-lyrical/actions/runs/34697410459
Activity
traversaro commentedon Sep 13, 2026
The originally reported issue was fixed by @sea-bass in #49 .
However, we have a much more tricky issue now on
linux-64. Due to an error on my side, I halted the first job after the mutex package was produced and uploaded, but now all the re-generated job fail with:See for example https://github.com/RoboStack/ros-lyrical/actions/runs/34724537008 .
That is strange as the package is indeed there: https://prefix.dev/channels/robostack-lyrical/packages/ros2-distro-mutex .
traversaro commentedon Sep 13, 2026
I even tried restarting the original job (the one that produced
ros2-distro-mutex) at https://github.com/RoboStack/ros-lyrical/actions/runs/34697487039 . But the problem is exactly the same.sea-bass commentedon Sep 13, 2026
Is there a way to delete what is on the channel first in case it was corrupted somehow, and then rerunning that generating job?
traversaro commentedon Sep 13, 2026
I asked the AI to investigate, and I think it found the problem: https://chatgpt.com/share/6aa68489-d93c-83ed-86c0-51fc626cba8f , that I reported in prefix-dev/prefix-dev#97 .
To actually fix the problem, as suggested by ChatGPT it was sufficient to manually reindex the channel:
curl -fSs -X POST \ -H "Authorization: Bearer ${PREFIX_API_KEY}" \ https://prefix.dev/api/v1/reindex/robostack-lyrical/linux-64and then restart the job.
traversaro commentedon Sep 13, 2026
Ok, now the problem is different:
sea-bass commentedon Sep 13, 2026
Oh, I got a few of those too. Seems you can just rerun those jobs and it will work next time. (Which it did; I just restarted)
But yes, I have encountered lots of little flakes like that.
sea-bass commentedon Sep 13, 2026
Just restarted the linux64 workflow again; the other flake that happens is sometimes the file that was just uploaded in a previous job doesn't yet get found by the next ones.
https://github.com/RoboStack/ros-lyrical/actions/runs/34754003472/job/103721571724
EDIT: Had to do this 7 more times for this build
Tobias-Fischer commentedon Oct 18, 2026
Addressed in the RoboStack monorepo, RoboStack/robostack, where all ROS 2 distributions are now built: the
vinca-ghaerror here (generated workflow over GitHub's 500 KiB) is handled by retrying with larger batches (RoboStack/robostack#96), and the flake where a just-uploaded package isn't found yet by the next job is retried there while the channel index catches up (RoboStack/robostack#22).🤖 Claude (AI assistant), on behalf of @Tobias-Fischer