ci: add workflow to auto-bump viam-cpp-sdk#75
Merged
Ethan (stuqdog) merged 3 commits intoJul 10, 2026
Conversation
Adds .github/workflows/bump-viam-cpp-sdk.yml, a daily scheduled workflow that opens a PR bumping the viam-cpp-sdk conan pin whenever a newer SDK release is published. Dependabot has no conan ecosystem, so the bump is done explicitly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
martha-johnston
approved these changes
Jul 2, 2026
As of ~2026-06-28 the windows-latest image became windows-2025-vs2026, which ships Visual Studio 18 "2026". Conan then selects the "Visual Studio 18 2026" CMake generator, which abseil's build cmake doesn't recognize, breaking the build. Pin to windows-2022 (VS 2022) so Conan emits "Visual Studio 17 2022", which every cmake in the graph understands. Stopgap until abseil/SDK support VS 18. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ethan (stuqdog)
force-pushed
the
bump-viam-cpp-sdk-workflow
branch
from
257b9c6 to
ce9e59a
Compare
| # windows-latest image became windows-2025-vs2026, which ships Visual Studio | ||
| # 18 "2026"; Conan then picks the "Visual Studio 18 2026" CMake generator, and | ||
| # abseil's build invokes a cmake that doesn't recognize it ("Could not create | ||
| # named generator"), breaking the build. windows-2022 keeps VS 2022, so Conan |
Contributor
There was a problem hiding this comment.
this comment can probably just be "pin instead of using windows-latest which was recently bumped to a version that breaks conan"
| tag="$(gh release view --repo viamrobotics/viam-cpp-sdk --json tagName --jq .tagName)" | ||
| latest="${tag#releases/v}" | ||
| # Currently pinned version in conanfile.py, e.g. viam-cpp-sdk/0.31.0 | ||
| current="$(grep -oE 'viam-cpp-sdk/[0-9]+\.[0-9]+\.[0-9]+' conanfile.py | head -1 | cut -d/ -f2)" |
Contributor
There was a problem hiding this comment.
let's get this somewhat more programatically using conan inspect . --format json | jq .version
lia (lia-viam)
approved these changes
Jul 10, 2026
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
3 participants
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.
Adds
.github/workflows/bump-viam-cpp-sdk.yml— a daily scheduled workflow (plusworkflow_dispatch) that opens/updates a PR bumping theviam-cpp-sdkconan pin inconanfile.pywhenever a newer SDK release is published on viamrobotics/viam-cpp-sdk.Why a custom workflow rather than Dependabot: the SDK is pinned via conan, which Dependabot has no ecosystem for.
conanfile.py.conan.lockvia conan if the repo has one (realsense does; the#recipe-revisionhash means a plain text replace is not enough).GIT_ACCESS_TOKENbot secret (same oneviam-python-sdk'supdate_protosuses) so the bump PR actually triggers CI.Opened as a draft for review.
🤖 Generated with Claude Code
Also included: fix for the Windows CI break (unrelated to the SDK bump)
build-module-windowsstarted failing on ~2026-06-28 when GitHub rolled thewindows-latestimage ontowindows-2025-vs2026(Visual Studio 18 "2026"). Conan then selects theVisual Studio 18 2026CMake generator, and abseil's build invokes a cmake that doesn't recognize it (Could not create named generator) — nothing to do with this PR's contents. Every dep that built with cmake 4.1.2 (bzip2/c-ares/zlib/zstd) succeeded on the same runner.Fix: pin the job to
windows-2022(VS 2022), so Conan emitsVisual Studio 17 2022, which every cmake in the graph understands — matching the environment that passed on 2026-06-08.Note: I first tried a narrower fix — a conan
[tool_requires]override forcing abseil onto cmake ≥4 — but it didn't work: it removed cmake 3.31.9 from the graph, yet abseil'sbuild()still executed an older cmake (its generator help topped out atVisual Studio 17 2022), so the scoped override never reached abseil's build PATH. Pinning the runner is the reliable fix. It's a stopgap until the abseil recipe / SDK dep graph supports VS 18.