Skip to content

vector_vendor: split into its own repo, pulled in via .repos - #431

Closed
Minipada wants to merge 3 commits into
jazzyfrom
feature/split-vector-vendor-repo-v2
Closed

vector_vendor: split into its own repo, pulled in via .repos#431
Minipada wants to merge 3 commits into
jazzyfrom
feature/split-vector-vendor-repo-v2

Conversation

@Minipada

Copy link
Copy Markdown
Owner

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 to jazzy once #429 merges and its branch is deleted.

Summary

  • vector_vendor moved out of this repo entirely, into its own repo: https://github.com/Minipada/vector_vendor (default branch jazzy, tagged v0.57.0). Same content vector_vendor: checked-in binary, no network fetch #429 landed here — same CMakeLists.txt, same checked-in tarballs, no network fetch, no Git LFS.
  • Why: every future Vector version bump adds ~106MB to whichever repo holds 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 off ros2_data_collection's own history.
  • Pulled in via ros2_data_collection.repos (vcstool), pinned to the tag v0.57.0 (not a branch) for reproducibility — a given ros2_data_collection commit always resolves the same vector_vendor content.
  • tools/e2e/Containerfile's toolchain-base stage runs vcs import (network required, same footing as the rosdep install right below it); every downstream colcon build — including Network-isolated build verification harness for vendor packages #423's --network=none check — builds against the already-materialized result.
  • dc_bridge needs no changes: it locates the installed binary via the fixed lib/vector_vendor/vector path and an <exec_depend>, both unaffected by which repo the source came from.
  • Updated doc/src/dc/setup.md (adds the vcs import step), four tools/e2e/scripts/*.sh that grepped vector_vendor/CMakeLists.txt for VECTOR_VERSION (now read from ros2_data_collection.repos instead), and stale CI/comment references.
  • .pre-commit-config.yaml's large-file exclude and REUSE.toml's tarball annotation removed — no longer relevant here, moved to the new repo.
  • ADR-0002 amended with the split's full reasoning.

Test plan

  • prek run --all-files --skip build-doc passes
  • ./tools/e2e/scripts/verify_network_isolation.sh: vendor-network-check stage still builds vector_vendor under --network=none (fetched via the new repo, through toolchain-base's vcs import)
  • Full production build: IMAGE_TAG=... TARGET=workspace ./tools/e2e/scripts/build.shcolcon build + full colcon test succeed end-to-end (634 tests, 0 errors, 0 failures), confirming vector_vendor survives the workspace stage's COPY . src/ros2_data_collection (Docker/Podman COPY merges into an existing directory, it doesn't clear it first — verified, not assumed)
  • Confirmed the new repo's REUSE compliance and that its CMakeLists.txt is byte-identical to the one landing in vector_vendor: checked-in binary, no network fetch #429 except two cross-repo comment references

Not part of this PR: actually bloom-release-ing vector_vendor into 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

Minipada and others added 2 commits August 28, 2026 02:23
… 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
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

codecov Bot commented Aug 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.93%. Comparing base (6403634) to head (e69f048).

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           
Flag Coverage Δ
cpp-jazzy 70.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Minipada

Copy link
Copy Markdown
Owner Author

Superseded by #432 — consolidated with #429 into a single PR targeting jazzy directly.

@Minipada Minipada closed this Aug 28, 2026
@Minipada
Minipada deleted the feature/split-vector-vendor-repo-v2 branch August 28, 2026 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant