fix: use explicit refs/tags/ in GitHub raw package.xml URLs - #156
Open
Tobias-Fischer wants to merge 1 commit into
Open
fix: use explicit refs/tags/ in GitHub raw package.xml URLs#156Tobias-Fischer wants to merge 1 commit into
Tobias-Fischer wants to merge 1 commit into
Conversation
ros2-gbp release tags look like "release/jazzy/foo_pkg/1.2.3-1" -- the short raw.githubusercontent.com <owner>/<repo>/<ref>/<path> form has to guess where a slash-containing ref ends and the path begins. That guess is inconsistently cached across CDN edges: the same URL 404s from some vantage points (including GitHub Actions runners, observed repeatedly and reproducibly on RoboStack/ros-jazzy CI) while resolving fine from others. The explicit refs/tags/<name> form removes the ambiguity and resolves reliably everywhere. A commit hash (rev) is already unambiguous and is left as-is. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-humble
that referenced
this pull request
Sep 10, 2026
RoboStack/vinca#156 fixes a real, reproducible bug: vinca's package.xml fetches use raw.githubusercontent.com's short <ref> form for ros2-gbp release tags like "release/jazzy/foo_pkg/1.2.3-1", which is ambiguous (where does the slash-containing ref end and the path begin?) and resolves inconsistently across CDN edges -- the same URL 404s from GitHub Actions runners while working fine everywhere else, which is what's been causing CI's persistent "Failed to fetch package.xml" failures. Pin to the fix commit directly (verified it contains this line's prior HEAD as an ancestor, so nothing else changes) rather than wait on review/merge. Revert to the plain RoboStack/vinca.git line once that PR merges. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-jazzy
that referenced
this pull request
Sep 10, 2026
RoboStack/vinca#156 fixes the real root cause of today's persistent, non-transient "Failed to fetch package.xml" failures: vinca's raw.githubusercontent.com URLs for ros2-gbp release tags (e.g. "release/jazzy/controller_interface/4.47.0-1") use the short <ref> form, which is ambiguous about where the slash-containing ref ends and the path begins, and resolves inconsistently across CDN edges -- confirmed the exact same URL 404s from GitHub Actions runners while working fine everywhere else (curl, a direct git clone of the tag). This was mistaken for a rate-limit issue in a previous commit; adding GITHUB_TOKEN auth didn't fix it because the problem was never about authentication. Pin to the fix commit directly (verified it contains this line's prior HEAD as an ancestor, so nothing else changes) rather than wait on review/merge. Revert to the plain RoboStack/vinca.git rev once that PR merges. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-rolling
that referenced
this pull request
Sep 10, 2026
Same fix as humble/jazzy: RoboStack/vinca#156 fixes vinca's ambiguous raw.githubusercontent.com URL construction for ros2-gbp release tags, which resolves inconsistently across CDN edges and was the real root cause behind a persistent, non-transient "Failed to fetch package.xml" failure pattern (confirmed on humble/jazzy CI; not yet observed here, but rolling's own Generate recipes step has no retry loop at all so it's if anything more exposed). Pin to the fix commit directly (verified it contains this line's prior HEAD as an ancestor) rather than wait on review/merge. Revert to the plain RoboStack/vinca.git rev once that PR merges. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-humble
that referenced
this pull request
Sep 10, 2026
The previous commit pinned to a fork commit based on current RoboStack/vinca master, which includes the newer rosdistro-cache-snapshot feature (PR #146). Our already-generated rosdistro_snapshot.yaml predates that machinery and isn't compatible with it, causing a new failure. Re-pin to RoboStack/vinca@1f1dca5 (the last commit before that feature landed) with the raw.githubusercontent.com tag-URL ambiguity fix (RoboStack/vinca#156) cherry-picked on top, so we keep the actual fix without pulling in the incompatible snapshot changes. Per instruction: do not regenerate rosdistro_snapshot.yaml itself, since that would pull in new package versions and a fresh round of patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-jazzy
that referenced
this pull request
Sep 10, 2026
The previous commit pinned to a fork commit based on current RoboStack/vinca master, which includes the newer rosdistro-cache-snapshot feature (PR #146). Our already-generated rosdistro_snapshot.yaml predates that machinery and isn't compatible with it, causing a new failure. Re-pin to RoboStack/vinca@1f1dca5 (the last commit before that feature landed) with the raw.githubusercontent.com tag-URL ambiguity fix (RoboStack/vinca#156) cherry-picked on top, so we keep the actual fix without pulling in the incompatible snapshot changes. Per instruction: do not regenerate rosdistro_snapshot.yaml itself, since that would pull in new package versions and a fresh round of patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
added a commit
to RoboStack/ros-rolling
that referenced
this pull request
Sep 10, 2026
The previous commit pinned to a fork commit based on current RoboStack/vinca master, which includes the newer rosdistro-cache-snapshot feature (PR #146). Our already-generated rosdistro_snapshot.yaml predates that machinery and isn't compatible with it, causing a new failure. Re-pin to RoboStack/vinca@1f1dca5 (the last commit before that feature landed) with the raw.githubusercontent.com tag-URL ambiguity fix (RoboStack/vinca#156) cherry-picked on top, so we keep the actual fix without pulling in the incompatible snapshot changes. Per instruction: do not regenerate rosdistro_snapshot.yaml itself, since that would pull in new package versions and a fresh round of patches. Co-Authored-By: Claude Sonnet 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
1 participant
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.
Summary
release/jazzy/foo_pkg/1.2.3-1-- the shortraw.githubusercontent.com/<owner>/<repo>/<ref>/<path>form has to guess where a slash-containing ref ends and the path begins.refs/tags/<name>form removes the ambiguity and resolves reliably everywhere. A commit hash (rev) is already unambiguous and is left as-is.Motivation
This was mistaken for a rate-limiting issue at first (GitHub's raw content requests were unauthenticated), but adding auth didn't fix it. Directly comparing the two URL forms confirmed the ambiguous short form is the actual culprit.
Test plan
vinca/test_github_raw_url.pycovering: tag ref gets therefs/tags/prefix, rev (commit hash) ref is left bare, and the additional-folder/custom-xml-name case still works with the prefix.vinca/test_snapshot_metadata.py's mocked URLs to match the new format (3 previously-passing tests hardcoded the old URL shape).curlin both forms, and confirmed via a real git clone that the tag'spackage.xmlcontent is genuinely present and correct -- this was never a data/version issue, only a URL-ambiguity/CDN-caching one.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com