Repository navigation
CI and bot machinery: one shared pinning update, build_distros, network retries, vinca fixes - #92
Merged
Merged
Conversation
With every distribution on shared/pinning/conda_forge.yaml, the daily per-distribution update-conda-forge-pinning jobs would each rewrite that file (from their own dependencies) in competing pull requests. A distribution on the shared pinning now moves together with the others: the migrations are chosen for all of their dependencies, the file is written once, and each distribution's pins are re-rendered with its own rebuild plan, in one pull request (bot/update-conda-forge-pinning). A distribution with its own pinning in distro.yaml is still updated on its own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A PR builds every distribution as soon as it touches anything outside distros/<d>/, e.g. a one-distribution rebuild that also changes shared/ or tools/. build_distros lists the ones to build instead (reset to [] before merging, like evict_cache); read by `rs changed-distros`, which the PR build's plan step already uses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GitHub or prefix.dev being unreachable for a moment (git fetch, package download) ended multi-hour full-rebuild jobs four times in a day. `rs build` now goes through run_build, which retries such failures (at most twice); packages built before stay in the output folder, so a retry continues where it stopped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…xisting per distribution - vinca-snapshot skips packages whose package.xml can't be read (humble's affordance_primitives in the 2026-10-12 sync crashed it), RoboStack/vinca#174 - skip-existing only counts packages built for this distribution (a channel shared by several distributions made lyrical skip plotjuggler), RoboStack/vinca#175 - qt6-main is a cross-compiling build dependency too, like qt-main Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ing) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ABI check (linux-64)Each package this pull request built, compared with its newest released build (
rolling linux-64
Compared with the newest builds on https://repo.prefix.dev/tobias-fischer/robostack-distro-test/linux-64 and https://repo.prefix.dev/robostack-rolling/linux-64. Exported symbols are compared (the released packages are stripped, so struct layouts aren't); unchanged installed headers rule out layout and inline changes, changed ones are listed for review. Dependents to rebuild are the released ones linking to a changed library. A changed pin is part of the comparison. |
…nection error' The Intel macOS runners lost their connection to prefix.dev for several minutes at a time, longer than two one-minute retries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A file setting had to be reset before merging, and the reset itself changed a shared file, so the last run of the pull request built every distribution anyway. Labels aren't part of the commit: nothing to reset. The plan step reads them at run time, so a re-run sees labels added after the push; adding one doesn't start a build (a labeled trigger would cancel the running build on any label, e.g. automerge). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
that referenced
this pull request
Oct 14, 2026
… fixes it needed Rebuilt on main after #92/#93 (which took this pull request's CI/bot machinery): - shared/pinning/conda_forge.yaml 2026.10.09.13.11.31 with lyrical's migrations for every distribution; per-distribution pinning versions removed; zenoh unified at 1.10.1; jazzy keeps xtensor 0.25; openexr 3.4 in the shared overrides; rebuild bumps for the packages the changed pins affect - Qt5 rosdep keys map to Qt6 (shared); humble and jazzy keep Qt5 in their own robostack.yaml; plotjuggler(_ros) keep Qt5; rolling's rviz_visual_tools 4.2.0 - rolling: rtabmap 0.23.13 (jazzy's release), python_qt_binding with PyQt6 on macOS - libpointmatcher on Windows: CMake config files together in share/libpointmatcher/cmake - moveit_ros_visualization (win): export the plugin targets too Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The machinery from #82, split out so it can be merged without the conda-forge pinning update (which needs a full CI run). Nothing here changes a package; the PR build only smoke-tests rolling (
build:rollinglabel).update-pinningonce per distribution, so every day it refreshed one pull request per distribution (lyrical: update conda-forge pinning to 2026.10.14.02.57.01 #84–humble: update conda-forge pinning to 2026.10.14.02.57.01 #87), each starting a full PR build. Now it runsrs update-pinningonce: distributions on the shared pinning (shared/pinning/conda_forge.yaml) move together, and one with its own pinning is updated in the same pull request.build:<distro>PR labels: a PR builds the distributions it changes, i.e. all of them as soon as it touches anything outsidedistros/<distro>/. Withbuild:<distro>labels it builds only those (e.g. a humble rebuild that also changesshared/ortools/). Labels aren't part of the commit, so there is nothing to reset before merging. The plan step reads them at run time (gh pr view), so a re-run sees labels added after the push; adding a label doesn't start a build by itself (alabeledtrigger would cancel the running build on any label, e.g.automerge). This pull request hasbuild:rolling.vinca-snapshotskips packages whosepackage.xmlcan't be read (vinca-snapshot: skip packages whose package.xml can't be read vinca#174), skip-existing only counts packages built for the same distribution (Skip-existing: only count packages built for this distribution vinca#175),qt6-mainis a cross-compiling build dependency likeqt-main. Checked: the recipes to build for lyrical and rolling are identical to main's.After this is merged, #82 keeps only the pinning update and the package fixes that came with it, and #84–#87 can be closed.
🤖 Generated with Claude Code