Pin the publish workflow's Windows runner to windows-2022

[Nicolas Palpacuer (NickPPC)]

Summary

The 0.1.1-rc3 release failed (run 30477264663). GitHub's windows-latest image now ships Visual Studio 2026, so conan detects msvc 195 and asks CMake for a generator that image's CMake does not have:

bzip2/1.0.8: settings: os=Windows compiler=msvc compiler.version=195
bzip2/1.0.8: RUN: cmake -G "Visual Studio 18 2026" ...
CMake Error: Could not create named generator Visual Studio 18 2026
Generators
  Visual Studio 17 2022        = Generates Visual Studio 2022 project files.
  Visual Studio 16 2019        = Generates Visual Studio 2019 project files.
  ...

The first dependency built from source (bzip2) dies at the configure step and make conan-pkg fails (Makefile:69). The other three platforms were only cancelled by fail-fast and publish was skipped — the release job is all-or-nothing.

Unrelated to any code change; the runner image moved.

Changes

• .github/workflows/publish.yml: Pin the windows/amd64 matrix entry to windows-2022, matching what build.yml already does, with the same explanatory comment.

Why this only broke at release time

The two workflows disagreed about the Windows runner:

workflow	runner
build.yml:12	windows-2022 — "pin instead of using windows-latest which was recently bumped to a version that breaks conan"
publish.yml:28	windows-latest ← this PR

Someone already hit this and pinned build.yml, but publish.yml was never updated. So every PR built Windows against a good image while the release path stayed on the broken one, and nothing surfaced until a release was actually cut.

Testing

• publish.yml parses, and the matrix resolves as expected:

  linux/amd64      -> ubuntu-latest
  darwin/arm64     -> macos-latest
  linux/arm64      -> ubuntu-22.04-arm
  windows/amd64    -> windows-2022
  

• No windows-latest runner remains in either workflow (the two matches left are the explanatory comments).
• Not verifiable before merge: publish.yml only triggers on release, so the fix is confirmed by cutting the next release candidate. The other three platforms were cancelled rather than failed, so they are unproven for this tag — if one of them also breaks, it will surface on the retry.

Follow-ups worth their own tickets

• build.yml and publish.yml duplicate their build setup with no shared source of truth. That duplication is precisely how this drift happened — the pin was applied to one and not the other. A composite action or reusable workflow would make this class of bug impossible.
• Pinning to windows-2022 is a stopgap; that image will eventually be retired. The durable fix is to make the build work on whatever MSVC is current, most likely by ensuring a CMake new enough for the detected toolset.
• This is the third distinct "toolchain moved underneath us" failure in this repo recently, alongside the unbounded xtensor and boost ranges that break cloud builds. The common thread is unpinned build environments.

Claude Code Prompts Used

• "I have merged Bump viam-cpp-sdk to 0.38.1 and drop Reconfigurable #80 and tried to create a release. It failed. Can you llok into https://github.com/viam-modules/orbbec/actions/runs/30477264663?"
• "yes open a PR with that fix"

🤖 Generated with Claude Code