Repository navigation
ci: bump pinned RELAY conformance validator to v2.0.4 - #96
Merged
Merged
Conversation
RELAY tagged v2.0.4 today to fix issue #70: go.mod's module path hadn't picked up the /v2 suffix required by Go's semantic import versioning after the v2.0 MAJOR bump, making v2.0.0+ tags uninstallable via go install/go get. cpp-RCP builds RELAY from a local checkout rather than go install, so it was never actually blocked by that bug, but the relay-conform job's pin (issue #83 / cpp-RCP-15) is now stale and should track a current tagged release. Bumps the "Checkout RELAY (authoritative conformance validator)" step's ref from 3344b3d1a6a4d870d26c81c6f3c3ff5ca2930e16 (v2.0.2) to 810d1877362145a407b865426bb007657e42d00f (v2.0.4) — the tag's actual commit SHA, not the annotated tag object SHA (f3eeb69d...), which resolves to this same commit but isn't itself a commit. Verified locally before pushing, building RELAY at this exact pinned commit the same way CI does: - `relay conform --strict build/cpp-rcp` PASSES. - `relay interop --strict --protocol RCP build/cpp-rcp` fails only because cpp-RCP has never implemented the optional `convert` subcommand (confirmed pre-existing and identical against the old v2.0.2 pin, so not a regression from this bump). Per RELAY spec §20.1/§20.3, the interop/behavioural-conformance CI gate applies "once convert is implemented" and is required only for the Tooling-conformant tier (convert + subscribe --format json + streaming send --format json); cpp-RCP is Core-conformant only and has never claimed convert in its capabilities, so this is a legitimate, known scope boundary, not a conformance gap to fix here. Non-strict interop (matching cpp-RCP's actual capabilities) reports SKIP/PASS. - Reviewed RELAY spec/CHANGELOG.md v2.0.1-v2.0.4: all four are tooling/doc/bug-fix patch releases with SpecVersion unchanged at 2.0 (no normative change), so no RCP-side canonical-type or wire-format work is needed. Also ran this repo's full local build/test suite against the bumped pin: cmake+ninja build (213/213 targets), ctest (52/52 passed), clang-tidy scoped to tests/*.cpp (clean aside from a pre-existing, untouched-by-this-change bugprone-infinite-loop false positive in test_request.cpp from a newer local clang-tidy than CI's pinned clang-14/Ubuntu-22.04 toolchain), and the ASan/UBSan test_regmap job (132 assertions, 23 test cases, clean). No cpp-FuSa binary is available in this local environment to run standalone. No behavior change and no conformance gap found, so no version bump (cpp-rcp stays at 2.19.0): CI-workflow-only change, consistent with this repo's convention of reserving version bumps for commits that touch library code or behavior. Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
6 of 7 tasks
SoundMatt
added a commit
that referenced
this pull request
Jul 31, 2026
Both workflow files that build the cpfusa safety-tooling binary from source cloned it with `git clone --depth=1 https://github.com/SoundMatt/cpp-FuSa /tmp/cpfusa` — no --branch/tag, so every CI run built whatever commit happened to be on cpp-FuSa's default branch at that moment. This is a floating-dependency policy violation (standing decision, confirmed 2026-07-28: pin every repo, every language): an unpinned checkout means CI pass/fail can change with no cpp-RCP-side change at all, which isn't reproducible and isn't something a reviewer can audit from the diff. Pins both occurrences to v0.18.0 (cpp-FuSa's latest release): - ci.yml's cpfusa-build job (shared by all cpfusa-* jobs via upload/download-artifact) - release.yml's regenerate-safety-artifacts job (tag-triggered, builds its own cpfusa independently rather than reusing ci.yml's artifact) Verified locally before pushing, building cpfusa v0.18.0 from source the same way CI now will and running every cpfusa subcommand either workflow invokes against cpp-RCP's own tree: - ci.yml set: check, lint, cyber, trace (incl. --req-coverage 100), qualify, vuln, verify, analyze, impact, metrics, report — all exit 0, 0 errors. - release.yml set: fmea --cyber, safety-case, tara, release (SBOM/ provenance), sas, sci, audit-pack, badge, report — all exit 0. iso26262/iec61508/do178 gap-report commands exit 1 as already documented in release.yml's comments (non-gating `|| true`, pre-existing stub-bridge gaps against ASIL-B/SIL-2/DAL-B thresholds, not new). - hara (display) — 0 issues. No new or different ERROR-level findings vs. whatever was floating before this pin: this is a clean, no-op-for-findings version lock. (One local-only false alarm caught and ruled out along the way: an initial `cpfusa lint` run showed 5 errors, all inside build/_deps/catch2-src — a FetchContent-vendored dependency that only existed because a full cmake build had been run in that checkout first. CI's actual cpfusa-lint job never runs cmake, so it never sees that path; re-running against a clean checkout with no build/ directory confirmed 0 errors.) Also ran this repo's full local build/test suite against the pin: cmake+ninja build (213/213 targets, twice in separate checkouts), ctest (52/52 passed, twice), and clang-tidy scoped to tests/*.cpp (clean aside from the same pre-existing bugprone-infinite-loop false positive in test_request.cpp already documented in commit 181e6e2/#96 as a newer-local-clang-tidy-vs-CI's-pinned-clang-14 artifact — this change touches no C++ source, so it cannot be the cause). No behavior change and no conformance gap found, so no version bump (cpp-rcp stays at 2.19.0): CI-workflow-only change, consistent with this repo's convention of reserving version bumps for commits that touch library code or behavior. Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
10 tasks
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.
Summary
RELAY tagged v2.0.4 today, fixing #70:
go.mod's module path hadn't picked up the/v2suffix required by Go's semantic import versioning after the v2.0 MAJOR bump, making v2.0.0+ tags uninstallable viago install/go get. cpp-RCP builds RELAY from a local source checkout rather thango install, so it was never actually blocked by that bug — but therelay-conformjob's pin (issue #83 / cpp-RCP-15) is deliberately locked to a specific commit for reproducibility, and that pin is now two patch releases stale.Bumps the "Checkout RELAY (authoritative conformance validator)" step in
.github/workflows/ci.ymlfrom:to:
Note:
810d187...is the commit thev2.0.4tag points at, not the tag itself. RELAY'sv2.0.4is an annotated tag, whose own object SHA isf3eeb69d...— that SHA does resolve viagit fetch/actions/checkout(GitHub peels it to the underlying commit), but it isn't a commit SHA the way the existing v2.0.2 pin is, so I used the actual commit SHA here to keep the pin consistent with this repo's existing convention (and with whatgit log/GitHub's UI show when someone inspects the pinned ref directly)..github/workflows/release.ymland everywhere else in the repo were checked — the RELAY pin only appears inci.yml.Verification performed before opening this PR
810d1877362145a407b865426bb007657e42d00f, built./cmd/relaylocally — the same way CI'srelay-conformjob now will.cpp-rcp's CLI (cmake -B build -DRELAY_BUILD_CLI=ON -G Ninja && cmake --build build --target cpp-rcp).relay conform --strict build/cpp-rcp→ PASS (all three §12 checks).relay interop --strict --protocol RCP build/cpp-rcp→ fails, but only because cpp-RCP has never implemented the optionalconvertsubcommand. I confirmed this is pre-existing and unrelated to this bump by running the identical check against the old v2.0.2 pin — same failure. Per RELAY spec §20.1/§20.3, the interop/behavioural-conformance CI gate applies "onceconvertis implemented" and is only required for the Tooling-conformant tier (convert+subscribe --format json+ streamingsend --format json); cpp-RCP is Core-conformant only and has never declaredconvertin its capabilities (cpp-rcp capabilitieslists["version","capabilities","status","send"]). This is a legitimate, known scope boundary, not a conformance gap introduced by this change — non-strictrelay interop(matching cpp-RCP's actual capabilities) reportsSKIP/PASS.spec/CHANGELOG.mdv2.0.1–v2.0.4 entries: all four are tooling/doc/bug-fix patch releases withSpecVersionunchanged at2.0(no normative change) — a Go-tooling installability fix (v2.0.4), a goroutine-leak fix inrouter.Runplus doc corrections (v2.0.3), and two docstring/test-strengthening patches aroundrcp.ToMessage/FromMessage(v2.0.2, v2.0.1). None require RCP-side canonical-type or wire-format changes in cpp-RCP.cmake --build build --parallel— 213/213 targets built clean.ctest --test-dir build— 52/52 passed.clang-tidyscoped totests/*.cpp(matching the CI job) — clean, aside from a pre-existingbugprone-infinite-loopfalse positive intests/test_request.cppfrom a newer local clang-tidy (22.1.8) than CI's pinned clang-14/Ubuntu-22.04 toolchain; confirmed viagit diff main --statthat this PR does not touch that file.test_regmapjob — 132 assertions, 23 test cases, clean.cpp-fusabinary is available in this local environment to run standalone; the CI-side FuSa gates are unaffected by this change (workflow-only diff).Why no version bump
This is a CI-workflow-only change with no library code or behavior change, and the pre-existing
interopgap is confirmed unrelated to it. Per this repo's convention (e.g. recentfix:commits #90–#95 land within a cycle without bumpingCMakeLists.txt'sPROJECT_VERSION, while substantive RELAY-spec-driven refactors likec0367d0do bump patch),cpp-rcpstays at2.19.0.Test plan
relay conform --strictagainstcpp-rcpbuilt at the new pin — PASSrelay interop --strict --protocol RCPagainstcpp-rcp— pre-existing gap confirmed unrelated to this bump (see above)ctestsuite — 52/52 passedclang-tidy(tests/*.cpp) — clean modulo unrelated pre-existing local-toolchain false positivetest_regmap— clean