What
Three satellite projects (pacs_bridge, dicom_viewer, messaging_system) use inconsistent vcpkg configuration compared to the 8 core ecosystem projects. This epic tracks the standardization effort.
Current State
| Project |
vcpkg-configuration.json |
builtin-baseline |
Overrides |
Custom Registry |
| Core 8 projects |
Yes |
No |
Yes (gtest 1.17.0, benchmark 1.9.5, etc.) |
kcenon/vcpkg-registry |
| pacs_bridge |
No |
a42af01b... |
Empty |
None |
| dicom_viewer |
No |
84bab45d... |
None |
None |
| messaging_system |
No |
No |
None |
None |
Expected State
All 11 projects use identical vcpkg-configuration.json with:
- Default registry baseline:
d90a9b159c08169f39adcd1b0f1ac0ca12c4b96c
- Custom registry:
kcenon/vcpkg-registry baseline 77cc46d5ba5e2aef1581f2ec674f83e1ac906b43
- Consistent overrides for shared packages (gtest, benchmark, etc.)
CI Standardization
Additionally, ecosystem CI workflows use 3 different patterns for vcpkg setup:
| Pattern |
Projects |
Issue |
| A: vcpkg manifest mode (clone HEAD) |
logger, monitoring, network, messaging |
Unpinned vcpkg clone drifts from baseline |
| B: No vcpkg in CI |
common, thread, container, database |
N/A (system packages only) |
| C: Mixed/special |
pacs_system, pacs_bridge, dicom_viewer |
Inconsistent setup logic |
A reusable composite action will centralize vcpkg bootstrap, pinning, and caching.
Why
- Version drift: Satellite projects resolve different package versions than core projects (no shared overrides), causing build failures when mixing dependencies
- Registry gap: Without
vcpkg-configuration.json, satellite projects cannot consume kcenon-* packages from the custom registry
- CI instability: Cloning vcpkg from HEAD means CI builds use different vcpkg versions than declared in baseline, leading to non-reproducible builds
- Maintenance burden: 3 different CI patterns for the same operation across 11 repos
Sub-Issues
Acceptance Criteria
What
Three satellite projects (pacs_bridge, dicom_viewer, messaging_system) use inconsistent vcpkg configuration compared to the 8 core ecosystem projects. This epic tracks the standardization effort.
Current State
kcenon/vcpkg-registrya42af01b...84bab45d...Expected State
All 11 projects use identical
vcpkg-configuration.jsonwith:d90a9b159c08169f39adcd1b0f1ac0ca12c4b96ckcenon/vcpkg-registrybaseline77cc46d5ba5e2aef1581f2ec674f83e1ac906b43CI Standardization
Additionally, ecosystem CI workflows use 3 different patterns for vcpkg setup:
A reusable composite action will centralize vcpkg bootstrap, pinning, and caching.
Why
vcpkg-configuration.json, satellite projects cannot consumekcenon-*packages from the custom registrySub-Issues
vcpkg-configuration.jsonand add ecosystem overridesvcpkg-configuration.jsonand add ecosystem overridesvcpkg-configuration.jsonand ecosystem overridesAcceptance Criteria
vcpkg-configuration.jsonbuiltin-baselinefield removed from satellitevcpkg.jsonfiles (superseded byvcpkg-configuration.json)vcpkg installresolves without version conflicts