vector_vendor: split into its own repo, pulled in via .repos - #431
Closed
Minipada wants to merge 3 commits into
Closed
vector_vendor: split into its own repo, pulled in via .repos#431Minipada wants to merge 3 commits into
Minipada wants to merge 3 commits into
Conversation
… fetch Replace vector_vendor's file(DOWNLOAD ...) with the official Vector 0.57.0 release tarballs (x86_64 + aarch64, same bytes/checksums already pinned) checked into vector_vendor/prebuilt/. CMakeLists.txt now extracts and installs from the local file instead of fetching it over the network, so colcon build --packages-select vector_vendor succeeds under #423's --network=none harness. Not Git LFS: evaluated and briefly adopted mid-review after verifying (by tracing and empirically testing the actual bloom/vcstools release code) that LFS content does survive bloom's release-tarball export step, contrary to #421's original assumption. Reverted anyway for a simpler reason: GitHub's free LFS tier is 1GB storage/month, and each future Vector bump would add ~106MB of new, non-deduplicated LFS objects -- about 9 bumps before hitting that ceiling. A plain committed blob has no such quota; the tradeoff is ordinary git history growing by the same ~106MB per bump instead. See ADR-0002's amendment for the full reasoning and the LFS trace, kept for the record in case LFS needs revisiting later. Closes #424 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019hV3DGw8o1QKsYbo8fQaS9 Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Every future Vector version bump adds ~106MB of binary content to whichever repo holds vector_vendor's CMakeLists.txt (see the previous commit/ADR-0002 amendment), and git never deduplicates that across commits. Move vector_vendor out of ros2_data_collection entirely, into its own repo (github.com/Minipada/vector_vendor, default branch jazzy), so that growth lands there instead of here -- ros2_data_collection's own history no longer carries it. Pulled into this workspace via ros2_data_collection.repos (vcstool), pinned to a tag (v0.57.0) rather than a branch, so a given commit here always resolves the same vector_vendor content. tools/e2e/Containerfile's toolchain-base stage runs the `vcs import` (network required, same as its rosdep install right below it); every downstream colcon build -- including #423's --network=none check -- builds against the already-fetched result, unaffected by where the source physically came from. Verified both paths directly: the vendor-network-check stage still builds vector_vendor under --network=none, and a full workspace build (colcon build + all 634 tests) succeeds with vector_vendor fetched from the external repo. dc_bridge needs no changes: it locates the installed binary at lib/vector_vendor/vector (the install path vector_vendor's own CMakeLists.txt sets, unchanged by the split) and declares <exec_depend>vector_vendor</exec_depend> in package.xml -- both resolve identically regardless of which repo the source came from, since colcon discovers packages by scanning src/ for package.xml, not by git origin. This is a development-workspace convenience only (.repos/vcstool); it doesn't make vector_vendor apt-installable on its own -- that needs an independent bloom-release, not done here. See ADR-0002's amendment for the full reasoning. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019hV3DGw8o1QKsYbo8fQaS9 Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Minipada
changed the base branch from
feature/424-vector-vendor-checked-in-binary-no-netwo
to
jazzy
August 28, 2026 10:57
Signed-off-by: David Bensoussan <d.bensoussan@proton.me>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## jazzy #431 +/- ##
=======================================
Coverage 70.93% 70.93%
=======================================
Files 119 119
Lines 7401 7401
=======================================
Hits 5249 5249
Misses 2152 2152
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Aug 28, 2026
Owner
Author
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.
Stacked on #429
This PR targets #429's branch, not
jazzy— it depends on #429 landing first (this diff only shows the incremental change on top of it). GitHub should auto-retarget tojazzyonce #429 merges and its branch is deleted.Summary
vector_vendormoved out of this repo entirely, into its own repo: https://github.com/Minipada/vector_vendor (default branchjazzy, taggedv0.57.0). Same content vector_vendor: checked-in binary, no network fetch #429 landed here — sameCMakeLists.txt, same checked-in tarballs, no network fetch, no Git LFS.vector_vendor, non-deduplicated by git, forever (per vector_vendor: checked-in binary, no network fetch #429's ADR-0002 amendment). Isolating that growth in its own repo keeps it offros2_data_collection's own history.ros2_data_collection.repos(vcstool), pinned to the tagv0.57.0(not a branch) for reproducibility — a givenros2_data_collectioncommit always resolves the samevector_vendorcontent.tools/e2e/Containerfile'stoolchain-basestage runsvcs import(network required, same footing as the rosdep install right below it); every downstreamcolcon build— including Network-isolated build verification harness for vendor packages #423's--network=nonecheck — builds against the already-materialized result.dc_bridgeneeds no changes: it locates the installed binary via the fixedlib/vector_vendor/vectorpath and an<exec_depend>, both unaffected by which repo the source came from.doc/src/dc/setup.md(adds thevcs importstep), fourtools/e2e/scripts/*.shthat greppedvector_vendor/CMakeLists.txtforVECTOR_VERSION(now read fromros2_data_collection.reposinstead), and stale CI/comment references..pre-commit-config.yaml's large-file exclude andREUSE.toml's tarball annotation removed — no longer relevant here, moved to the new repo.Test plan
prek run --all-files --skip build-docpasses./tools/e2e/scripts/verify_network_isolation.sh:vendor-network-checkstage still buildsvector_vendorunder--network=none(fetched via the new repo, throughtoolchain-base'svcs import)IMAGE_TAG=... TARGET=workspace ./tools/e2e/scripts/build.sh—colcon build+ fullcolcon testsucceed end-to-end (634 tests, 0 errors, 0 failures), confirmingvector_vendorsurvives theworkspacestage'sCOPY . src/ros2_data_collection(Docker/PodmanCOPYmerges into an existing directory, it doesn't clear it first — verified, not assumed)CMakeLists.txtis byte-identical to the one landing in vector_vendor: checked-in binary, no network fetch #429 except two cross-repo comment referencesNot part of this PR: actually
bloom-release-ingvector_vendorinto rosdistro (manual, maintainer-only, per this repo's existing policy) —.repos/vcstool is the dev-workspace-only mechanism until that happens.🤖 Generated with Claude Code
https://claude.ai/code/session_019hV3DGw8o1QKsYbo8fQaS9