Repository navigation
Add vinca-rebuild-plan: rebuild only what a pinning change affects - #168
Merged
Tobias-Fischer merged 1 commit intoOct 10, 2026
Merged
Conversation
Packages that use a changed conda_build_config.yaml pin in their build or host requirements, plus everything that depends on them (host or run, transitively), instead of a full rebuild. The platform loop of dependencies_from_vinca is shared as _platform_configurations. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to Tobias-Fischer/robostack-distros
that referenced
this pull request
Oct 8, 2026
… changed pins affect - rs <distro> update-pinning moves the distribution's pinning (its distro.yaml version, or shared/pinning for distributions that follow it) to the latest conda-forge-pinning with the migrations done for its dependencies - vinca-rebuild-plan (RoboStack/vinca#168) decides what to rebuild: packages using a changed pin and everything depending on them get a per-package build number, the mutex a new build at the same version; more than half affected means a full rebuild - the PR lists the packages and why, the migrations used / waiting for our dependencies' feedstocks / not concerning the distribution, and the conflicts the new pins add (labelled dependency-conflict) - bot: one pinning job per distribution every day - check_dependency_compat.py: requirements of every selected package from vinca (--source recipes for the old behaviour), retries, --stale handles ros2-* names and -devel pins Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to Tobias-Fischer/robostack-distros
that referenced
this pull request
Oct 9, 2026
… changed pins affect - rs <distro> update-pinning moves the distribution's pinning (its distro.yaml version, or shared/pinning for distributions that follow it) to the latest conda-forge-pinning with the migrations done for its dependencies - vinca-rebuild-plan (RoboStack/vinca#168) decides what to rebuild: packages using a changed pin and everything depending on them get a per-package build number, the mutex a new build at the same version; more than half affected means a full rebuild - the PR lists the packages and why, the migrations used / waiting for our dependencies' feedstocks / not concerning the distribution, and the conflicts the new pins add (labelled dependency-conflict) - bot: one pinning job per distribution every day - check_dependency_compat.py: requirements of every selected package from vinca (--source recipes for the old behaviour), retries, --stale handles ros2-* names and -devel pins Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
|
Not directly related to this, but I wonder if it ever made sense at all to set explicit build numbers in pkg_additional_info.yaml. in the end we want always to specify an rebuild number that should we add to the base buils number specified in vinca.yaml |
traversaro
approved these changes
Oct 10, 2026
Contributor
Author
I opened an issue #173 to follow this up |
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
2 participants
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.
So far a change of
conda_build_config.yaml(a new conda-forge-pinning version or migration) means a full rebuild.vinca-rebuild-planworks out which packages actually need one:conda_build_config.yamlwhose values differ (a changedpin_run_as_buildentry counts too);zip_keysetc. are ignored.It reads the requirements vinca generates (
generate_output(..., dependencies_only=True)) for every selected package on the given platforms, so no recipes have to be written andskip_existingdoesn't hide anything. The platform/config loop ofdependencies_from_vincais now shared as_platform_configurations.Example (humble, linux-64, a hypothetical
pclbump): 50 of 1118 packages (18 usepcldirectly, 32 depend on those) instead of all of them. Together with a new build of the mutex at the same version (mutex_package.build_number), every other published package stays installable.The approach is different from #64: instead of editing
vinca.yamlto mark rebuilds, it only produces the plan; the caller sets per-package build numbers (e.g. inpkg_additional_info.yaml).Tests for the pin diff, the closure and the CLI added.
🤖 Generated with Claude Code