vcpkg registry for hsm-collector (in-repo)

[lotgon]

Makes this repository usable as a vcpkg registry so many downstream projects can consume the native C++ collector with vcpkg install hsm-collector — no checkout of the HSM sources required. (Chosen over conan: Windows/MSVC/Visual Studio target, no server needed. Chosen over a raw prebuilt zip: the collector is a static lib with transitive deps — vcpkg resolves libcurl/iphlpapi/pdh for the consumer.)

What's here

• ports/hsm-collector/ — the registry port (portfile.cmake + vcpkg.json + copyright). Unlike the in-repo overlay port (src/native/collector/vcpkg-port, which builds from adjacent source for CI), this fetches a tagged source tarball (collector-v0.6.2, pinned by SHA512) so it's reproducible for external consumers.
• versions/baseline.json + versions/h-/hsm-collector.json — the vcpkg version database (0.6.2 → the port's git-tree).
• Source tag collector-v0.6.2 pushed on master (8c90a0d7) — the stable ref the port downloads.
• Version-skew fix: the overlay port and conan recipe were stuck at 0.4.0; aligned both to the library version 0.6.2.
• .github/workflows/hsm-collector-registry.yml — validates (1) the version DB matches the ports (x-verify-versions) and (2) the registry port installs + a consumer links against it.

How a consumer uses it (after merge)

vcpkg-configuration.json adds this repo as a git registry for hsm-collector, then vcpkg install hsm-collector[http]. The wiki "C++ Data Collector" page gets an "Install via vcpkg" section once this lands (baseline = a merged master commit).

Maintenance

New collector version = push a collector-v<semver> tag, bump REF/SHA512 + vcpkg.json version, run vcpkg x-add-version hsm-collector.

🤖 Generated with Claude Code

[github-actions]

Review: vcpkg registry for hsm-collector (#1267)

Nicely scoped, well-documented change. The port recipe, version database, and CI lane are internally consistent and the recipe mirrors the established overlay port. I verified the two things a registry stands or falls on:

• Version DB is consistent. versions/h-/hsm-collector.json records git-tree: bbc02d75…, which matches the actual git tree object of ports/hsm-collector at this commit — so x-verify-versions will pass. Sharding into h- is correct.
• CURL dependency is handled correctly. hsm_collectorConfig.cmake.in guards find_dependency(CURL) behind if(@HSM_COLLECTOR_HTTP@), so a consumer of the [http] feature will resolve curl (the static core propagates it as $<LINK_ONLY:>). Good.

No correctness bugs or security issues in the diff. The comments below are about CI coverage and maintainability.

Medium — the http feature (the headline scenario) is never exercised by CI

The PR pitch is vcpkg install hsm-collector[http], but the new lane installs the bare port:

vcpkg install hsm-collector --overlay-ports=ports --triplet x64-windows

So the entire curl transport path — the curl dependency resolution, HSM_COLLECTOR_HTTP=1 compile, and the find_dependency(CURL) branch of the config file — goes unvalidated here. That's exactly the code most likely to break for external consumers (transitive dep resolution through the static archive). Consider adding an install of hsm-collector[http] (and a consumer that actually links it) so the feature you advertise is on the tested path.

Medium — Windows-only / single-triplet coverage vs. an !uwp port

vcpkg.json declares "supports": "!uwp", and the existing native-collector-conformance.yml overlay-consume job already proves the collector installs and links on a non-Windows matrix. Yet this registry lane runs only windows-latest / x64-windows. The header comment ("Windows-only: the aggregator target is Windows/MSVC") is contradicted by that existing cross-platform overlay job. If the registry genuinely targets !uwp, the lane understates coverage; if it's truly Windows-only, consider narrowing supports so the manifest doesn't over-promise.

Low — consumer is built but never run

The existing overlay-consume job in native-collector-conformance.yml ends with a Run consumer step (executes hsm_console_standalone). This new lane stops at cmake --build … and never runs the binary. Running it is cheap and turns a compile/link check into a real smoke test (catches missing transitive symbols and load-time failures that a build alone won't). Worth mirroring the existing lane.

Low — on.push.paths is asymmetric with pull_request.paths

pull_request triggers on src/native/collector/** but push does not. Since the consumer step compiles src/native/collector/examples/console/standalone + ../main.cpp, a push that changes the example won't re-run this lane. Either add src/native/collector/** to the push filter or drop it from the PR filter for symmetry.

Low (by design, worth documenting) — branch example vs. tagged package

The consumer step compiles the branch-HEAD example (../main.cpp) against the tagged-v0.6.2 installed headers (the registry port fetches the tag, not the working tree). Two consequences: a branch that adds a new wrapper API to main.cpp will fail this lane against the older tagged headers until a new tag is cut; and conversely a breaking change to the wrapper header on the branch is not what gets installed, so it can't be caught here. This is inherent to pinning a released tag — just flag it so a red build on this lane isn't misread as a registry defect.

Maintainability — the version now lives in several places

0.6.2 is duplicated across ports/hsm-collector/vcpkg.json, src/native/collector/vcpkg-port/vcpkg.json, and conanfile.py, plus REF/SHA512 in the registry portfile and the versions/ DB. This PR itself exists partly to fix a 0.4.0 → 0.6.2 skew between those manifests, which shows how easily they drift. Consider a single source of truth (e.g. derive the manifests from the C ABI version already tracked in hsm_collector.h, or a small CI check that asserts all version strings agree) so the next bump can't half-land.

Could not verify offline

The lane depends on the tag collector-v0.6.2 existing with a body whose tarball matches the pinned SHA512. The PR body states the tag was pushed on master (8c90a0d7); worth a final confirmation that the tag is present and the SHA512 matches, since a mismatch there fails the whole lane at install time (and x-verify-versions won't catch a wrong SHA512 — only the git-tree).

---

Overall: solid, low-risk addition. The main gap is that CI validates the least-interesting configuration (bare port, x64-windows, build-only) while the advertised use case is [http] across !uwp.

🤖 Generated with Claude Code

[github-actions]

PR #1267 Review — vcpkg registry for hsm-collector

Sets up this repo as a vcpkg registry for hsm-collector: a new registry port (ports/hsm-collector/) that fetches a tagged source tarball, the version database (versions/), a validation workflow, and version bumps (0.4.0 → 0.6.2) for the overlay port and conanfile.

Overall this is a clean, well-documented change. The version DB is internally consistent (I verified the git-tree in versions/h-/hsm-collector.json matches the committed ports/hsm-collector tree, and the port's CMake option names all exist in CMakeLists.txt). The bumps to conanfile.py and vcpkg-port/vcpkg.json correctly resolve pre-existing drift — CMakeLists.txt on master was already at 0.6.2 while those two files lagged at 0.4.0. A few points below.

Findings

1. push trigger has no branch filter → wasteful double runs (maintainability / CI cost)
.github/workflows/hsm-collector-registry.yml

on:
  push:
    paths:
      - 'ports/hsm-collector/**'
      - 'versions/**'
      ...

Every other collector workflow scopes push to the integration branches — e.g. native-collector-conformance.yml uses branches: [master, develop]. Without that filter, a push to any feature branch touching ports/ or versions/ runs a full windows-latest build, and for a branch with an open PR both the push and pull_request events fire on the same commit, so the (expensive) job runs twice. Recommend adding branches: [master, develop] to the push trigger to match the repo convention.

2. The workflow validates the port as an overlay, not as a registry (correctness of stated intent)
The header comment and job name state the workflow validates "that this repository works as a vcpkg registry," but the install step consumes the port via --overlay-ports=ports:

"$VCPKG_ROOT/vcpkg" install hsm-collector --overlay-ports=ports --triplet x64-windows

Overlay-port mode does not exercise the registry resolution path — it ignores versions/ entirely. What's actually validated is (a) the port recipe builds/fetches correctly and (b) versions/ is self-consistent (the separate x-ci-verify-versions step). That's a reasonable and pragmatic split, but it's not "registry consumption." If you want true end-to-end coverage, add a small consumer with a vcpkg-configuration.json declaring a filesystem/git registry pointing at this repo and do a manifest install. At minimum, consider softening the comment/step wording so it doesn't overclaim.

3. No draft-PR gate (minor CI cost)
The conformance workflow's jobs guard with if: github.event_name != 'pull_request' || github.event.pull_request.draft == false so heavy Windows jobs don't run on drafts. This new workflow has no such guard. Consider adding it for consistency.

4. copyright file diverged from the overlay port's version (minor)
ports/hsm-collector/copyright drops two lines that src/native/collector/vcpkg-port/copyright carries:

Copyright (c) SoftFx.

The repository does not ship a standalone LICENSE file; refer to the upstream repository for the
authoritative license terms.

Since the two ports are otherwise deliberately kept in sync, aligning the copyright text (and, if desired, the "no LICENSE file" comment near vcpkg_install_copyright in the portfile) avoids future confusion about which is canonical.

Notes (no action required)

• SHA512 for collector-v0.6.2 cannot be verified offline, but a wrong hash (or a missing tag) would fail the install step in CI, so it's self-checking — just confirm the workflow goes green before merge.
• The consumer step (unlike the conformance consume lane) only builds, it doesn't run the produced binary. Linking is the meaningful signal here, so this is fine; adding a run step would be a small bonus.
• Two ports now share the name hsm-collector (registry ports/ + overlay src/native/collector/vcpkg-port). They're used via distinct --overlay-ports paths and won't collide in practice; worth keeping in mind so future edits are applied to both.

No security concerns: pinned vcpkgGitCommitId, pinned source SHA512, VCPKG_DISABLE_METRICS, and no secrets used.

[github-actions]

Review: vcpkg registry for hsm-collector (in-repo) — PR #1267

Overall this is a clean, well-documented change. I verified the important invariants and they hold; findings below are mostly about CI coverage and minor polish, not correctness of the port itself.

What I verified ✅

• Version alignment is correct. src/native/collector/CMakeLists.txt (project(... VERSION 0.6.2)) and the header macros (HSM_COLLECTOR_VERSION_* = 0.6.2) are the source of truth; the bumps of conanfile.py and vcpkg-port/vcpkg.json from 0.4.0 → 0.6.2 bring the stale recipes into line with the actual library version.
• Version-DB git-tree is consistent. versions/h-/hsm-collector.json records bbc02d7505419f4a24e6c584d4a1d9643db4b6d9, which matches git rev-parse HEAD:ports/hsm-collector on the merge tree. Because a git subtree hash is content-addressed, the workflow's check is robust across the PR-merge vs. branch-head checkout difference.
• Port recipe is faithful to the working overlay port. Feature flag (http → HSM_COLLECTOR_HTTP), the -DHSM_COLLECTOR_BUILD_TESTS/EXAMPLES/INSTALL options, and the config fixup path (lib/cmake/hsm_collector) all match the CMake option names and install destination in CMakeLists.txt.
• The consumer example is buildable without [http]. examples/console/standalone only links hsm_collector::hsm_collector_cpp and ../main.cpp has no compile-time dependency on the HTTP transport, so installing the port without the feature is fine.
• No security concerns. Uses pull_request (not pull_request_target), no secrets, VCPKG_DISABLE_METRICS=1, and vcpkgGitCommitId is SHA-pinned.

Findings

1. (Medium) CI never exercises the registry mechanism end-to-end.
The install step uses --overlay-ports=ports, which is the same resolution path as the existing overlay lane — it does not go through git-registry resolution, so versions/baseline.json and the version database are never used as an actual registry during CI. The only thing validating the version DB is the static git-tree string comparison. A real registry-consume failure (e.g., a wrong baseline version in baseline.json, or a broken vcpkg-configuration.json handshake) would pass CI green. The PR is explicitly about making the repo usable as a registry, so consider adding a lane that consumes via a vcpkg-configuration.json git registry ("baseline": "<a merged master commit>") against a real vcpkg.json manifest. That's the invariant the feature actually ships.

2. (Minor) Trigger-path asymmetry between push and pull_request.
pull_request includes src/native/collector/** in its paths filter, but push does not. A direct push to master that changes the collector source (which is what the registry port packages via the tag) won't re-run this validation. If that asymmetry is intentional, a one-line comment would help; otherwise add src/native/collector/** to the push.paths list too.

3. (Minor) The registry-consume lane builds but doesn't run the consumer.
The existing overlay lane in native-collector-conformance.yml finishes with a "Run consumer" step; this new lane stops at cmake --build. Running the produced binary is cheap and catches link/runtime-only breakage. Consider mirroring the existing lane's run step.

4. (Low) Fragile git-tree extraction in the version-DB check.
grep -oiE '[0-9a-f]{40}' versions/h-/hsm-collector.json | head -1 happens to work because there's exactly one 40-hex string in the file, but it's positional and would silently pick the wrong token if the schema grows (e.g. a future port-version or a second entry). jq -r '.versions[0]["git-tree"]' is available on the runner and is unambiguous.

5. (Nit) PR description vs. implementation.
The description says the workflow validates the version DB via x-verify-versions, but the implementation deliberately uses a bespoke git-tree check instead (the inline comment explains why x-ci-verify-versions isn't applicable to a supplementary single-port registry). No code issue — just worth aligning the description so future readers aren't confused.

6. (Nit) Mutable action tags.
actions/checkout@v4 and lukka/run-vcpkg@v11 are tag-pinned (mutable) while vcpkgGitCommitId is correctly SHA-pinned. Not blocking and consistent with the rest of the repo's workflows, but SHA-pinning third-party actions is the more reproducible/supply-chain-safe choice.

Note (not blocking)

The SHA512 in portfile.cmake for the collector-v0.6.2 tarball can't be verified statically — it is self-checking, as a mismatch would fail the install step in CI.

Nice work — the recipe and version-DB wiring look correct; the main thing I'd push on is closing the gap between "validates the port" and "validates the registry" (finding #1).