Skip to content

ci: bump pinned RELAY conformance validator to v2.0.4 - #96

Merged
SoundMatt merged 1 commit into
mainfrom
chore/bump-relay-pin-v2.0.4
Jul 30, 2026
Merged

SoundMatt merged 1 commit into
mainfrom
chore/bump-relay-pin-v2.0.4

Conversation

@SoundMatt

Copy link
Copy Markdown
Owner

Summary

RELAY tagged v2.0.4 today, fixing #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 source 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 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.yml from:

ref: 3344b3d1a6a4d870d26c81c6f3c3ff5ca2930e16 # v2.0.2

to:

ref: 810d1877362145a407b865426bb007657e42d00f # v2.0.4

Note: 810d187... is the commit the v2.0.4 tag points at, not the tag itself. RELAY's v2.0.4 is an annotated tag, whose own object SHA is f3eeb69d... — that SHA does resolve via git 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 what git log/GitHub's UI show when someone inspects the pinned ref directly).

.github/workflows/release.yml and everywhere else in the repo were checked — the RELAY pin only appears in ci.yml.

Verification performed before opening this PR

  • Cloned RELAY, checked out 810d1877362145a407b865426bb007657e42d00f, built ./cmd/relay locally — the same way CI's relay-conform job now will.
  • Built 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 optional convert subcommand. 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 "once convert is implemented" and is only required for the Tooling-conformant tier (convert + subscribe --format json + streaming send --format json); cpp-RCP is Core-conformant only and has never declared convert in its capabilities (cpp-rcp capabilities lists ["version","capabilities","status","send"]). This is a legitimate, known scope boundary, not a conformance gap introduced by this change — non-strict relay interop (matching cpp-RCP's actual capabilities) reports SKIP/PASS.
  • Read RELAY's spec/CHANGELOG.md v2.0.1–v2.0.4 entries: all four are tooling/doc/bug-fix patch releases with SpecVersion unchanged at 2.0 (no normative change) — a Go-tooling installability fix (v2.0.4), a goroutine-leak fix in router.Run plus doc corrections (v2.0.3), and two docstring/test-strengthening patches around rcp.ToMessage/FromMessage (v2.0.2, v2.0.1). None require RCP-side canonical-type or wire-format changes in cpp-RCP.
  • Ran this repo's full local build/test suite against the bumped pin:
    • cmake --build build --parallel — 213/213 targets built clean.
    • ctest --test-dir build — 52/52 passed.
    • clang-tidy scoped to tests/*.cpp (matching the CI job) — clean, aside from a pre-existing bugprone-infinite-loop false positive in tests/test_request.cpp from a newer local clang-tidy (22.1.8) than CI's pinned clang-14/Ubuntu-22.04 toolchain; confirmed via git diff main --stat that this PR does not touch that file.
    • ASan/UBSan test_regmap job — 132 assertions, 23 test cases, clean.
    • No cpp-fusa binary 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 interop gap is confirmed unrelated to it. Per this repo's convention (e.g. recent fix: commits #90–#95 land within a cycle without bumping CMakeLists.txt's PROJECT_VERSION, while substantive RELAY-spec-driven refactors like c0367d0 do bump patch), cpp-rcp stays at 2.19.0.

Test plan

  • relay conform --strict against cpp-rcp built at the new pin — PASS
  • relay interop --strict --protocol RCP against cpp-rcp — pre-existing gap confirmed unrelated to this bump (see above)
  • Full ctest suite — 52/52 passed
  • clang-tidy (tests/*.cpp) — clean modulo unrelated pre-existing local-toolchain false positive
  • ASan/UBSan test_regmap — clean
  • CI green on this PR (pending)

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>
@SoundMatt
SoundMatt merged commit 181e6e2 into main Jul 30, 2026
21 checks passed
@SoundMatt
SoundMatt deleted the chore/bump-relay-pin-v2.0.4 branch July 30, 2026 22:47
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>
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