@htekdev/actions-debugger 1.0.13 → 1.0.15

package/errors/runner-environment/setup-java-distribution-required.yml

@@ -0,0 +1,108 @@
+id: runner-environment-039
+title: "setup-java Fails with 'Distribution Input Value Is Required' After v1 to v2 Migration"
+category: runner-environment
+severity: error
+tags:
+  - setup-java
+  - java
+  - distribution
+  - breaking-change
+  - temurin
+  - adoptopenjdk
+  - v2-migration
+patterns:
+  - regex: "Distribution input value is required"
+    flags: "i"
+  - regex: "'distribution' must be one of:.*temurin|adopt|zulu|liberica|corretto|microsoft|semeru"
+    flags: "i"
+  - regex: "actions/setup-java.*distribution.*required"
+    flags: "i"
+  - regex: "Input required and not supplied: distribution"
+    flags: "i"
+error_messages:
+  - "Error: Distribution input value is required. 'distribution' must be one of: temurin, adopt, zulu, liberica, corretto, microsoft, semeru, dragonwell, sapmachine, graalvm"
+  - "Error: Input required and not supplied: distribution"
+root_cause: |
+  In `actions/setup-java` v2 (released 2021), the `distribution` input became mandatory.
+  In v1, AdoptOpenJDK was the implicit default distribution and no `distribution` key was
+  needed. When workflows that were written for v1 are updated to use @v2, @v3, or @v4 without
+  adding a `distribution:` input, the action fails immediately.
+
+  This also occurs when:
+  - An organization adopts setup-java for the first time using documentation examples from an
+    older blog post or tutorial that predates v2
+  - A Dependabot PR bumps setup-java from @v1 to @v3 or @v4 without updating the inputs
+  - Internal action templates or reusable workflows reference setup-java without distribution
+
+  Available distributions (as of 2024-2026):
+  - `temurin` — Eclipse Temurin (recommended, successor to AdoptOpenJDK)
+  - `zulu` — Azul Zulu OpenJDK
+  - `corretto` — Amazon Corretto
+  - `microsoft` — Microsoft Build of OpenJDK
+  - `liberica` — BellSoft Liberica JDK
+  - `semeru` — IBM Semeru Runtime
+  - `dragonwell` — Alibaba Dragonwell
+  - `sapmachine` — SAP Machine
+  - `graalvm` — GraalVM Community Edition
+  - `adopt` — Legacy AdoptOpenJDK alias (still supported but deprecated; use temurin instead)
+
+  Note: `adopt` (AdoptOpenJDK) was renamed/rebranded to Adoptium / Eclipse Temurin.
+  Using `distribution: adopt` still works but `distribution: temurin` is the modern equivalent.
+fix: |
+  Add the `distribution:` input to all `actions/setup-java` steps. Use `temurin` as the
+  recommended default (it is the open-source successor to AdoptOpenJDK hosted by Adoptium).
+
+  If you need to match your production environment's exact JDK distribution, choose the
+  corresponding option from the available distributions list.
+fix_code:
+  - language: yaml
+    label: "Add required distribution input to setup-java"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # ❌ v1-style — fails on v2+
+            # - uses: actions/setup-java@v4
+            #   with:
+            #     java-version: '17'
+
+            # ✅ v2+ style — distribution is required
+            - uses: actions/setup-java@v4
+              with:
+                distribution: 'temurin'   # Eclipse Temurin (recommended)
+                java-version: '21'
+                cache: 'maven'            # optional: enables Maven dependency caching
+
+            - name: Build with Maven
+              run: mvn --batch-mode --update-snapshots package
+  - language: yaml
+    label: "Using Corretto (Amazon) or Zulu distributions"
+    code: |
+      # Amazon Corretto
+      - uses: actions/setup-java@v4
+        with:
+          distribution: 'corretto'
+          java-version: '21'
+
+      # Azul Zulu
+      - uses: actions/setup-java@v4
+        with:
+          distribution: 'zulu'
+          java-version: '17'
+prevention:
+  - "Always specify `distribution:` when using actions/setup-java v2 or later — there is no default."
+  - "Use `temurin` as the default distribution for open-source projects (it is the community-maintained successor to AdoptOpenJDK)."
+  - "When Dependabot bumps setup-java, check that the resulting PR also adds or preserves the `distribution:` input."
+  - "Review your org's reusable workflow templates and action wrappers for setup-java v1-style usage that lacks distribution."
+docs:
+  - url: "https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md"
+    label: "actions/setup-java — advanced usage and distribution options"
+  - url: "https://github.com/actions/setup-java/releases/tag/v2.0.0"
+    label: "actions/setup-java v2.0.0 release notes (distribution became required)"
+  - url: "https://adoptium.net/"
+    label: "Eclipse Temurin (Adoptium) — recommended open-source JDK distribution"
+  - url: "https://stackoverflow.com/questions/69595609/github-actions-actions-setup-java-distribution-input-required"
+    label: "Stack Overflow — setup-java distribution input required error"

package/errors/runner-environment/ubuntu-2204-precached-docker-removed.yml

@@ -0,0 +1,110 @@
+id: runner-environment-035
+title: "ubuntu-22.04 Pre-Cached Docker Images Removed — Cold Pulls Now Required"
+category: runner-environment
+severity: warning
+tags:
+  - ubuntu
+  - docker
+  - pre-cached
+  - runner-image
+  - pull-rate
+  - performance
+patterns:
+  - regex: "Unable to find image '.*' locally"
+    flags: "i"
+  - regex: "Pulling from (?:library/)?(?:node|python|postgres|redis|mysql|nginx|ubuntu|alpine).*\nDigest:"
+    flags: "im"
+  - regex: "docker: Error response from daemon.*manifest.*not found"
+    flags: "i"
+error_messages:
+  - "Unable to find image 'node:lts-alpine' locally"
+  - "Unable to find image 'postgres:15' locally"
+  - "Unable to find image 'redis:7-alpine' locally"
+  - "Pulling from library/node"
+  - "Pulling from library/postgres"
+root_cause: |
+  Starting January 12, 2026, GitHub removed all pre-cached Docker images from the
+  ubuntu-22.04 runner image to address disk space limits. Previously, commonly used
+  Docker images (node, postgres, redis, mysql, python, nginx, alpine, etc.) were
+  pre-pulled into the runner's local Docker image cache, so `docker pull` or
+  `docker run` on those images started immediately without a network pull.
+
+  After the change, ALL Docker images must be pulled from the registry at runtime.
+  This has two main effects:
+
+  1. **Longer job times**: Cold pulls for large images (node, python, postgres) add
+     30-120+ seconds per job depending on image size and registry speed.
+
+  2. **DockerHub rate limit exposure**: Workflows that previously never hit the
+     DockerHub anonymous pull rate limit (100 pulls/6h per IP) may now exceed it
+     once caching is removed — especially on parallel matrix jobs all pulling the
+     same image from the same runner subnet IP.
+
+  The change only affects ubuntu-22.04. Ubuntu 24.04 and other images were not
+  pre-caching Docker images in the same way.
+
+  Source: actions/runner-images#13472
+fix: |
+  **Option 1 — Authenticate to DockerHub** to raise the rate limit to 200 pulls/6h
+  (free account) or unlimited (Pro/Team).
+
+  **Option 2 — Use GitHub Container Registry (ghcr.io)** for your own images —
+  these never count against DockerHub rate limits and pull faster from GitHub runners.
+
+  **Option 3 — Upgrade to ubuntu-24.04** if the workflow is not tied to ubuntu-22.04
+  specific packages. The 24.04 image has current tooling and better long-term support.
+
+  **Option 4 — Add a docker/login-action step** before any Docker operations to
+  authenticate even with a free DockerHub account, which 2x the anonymous rate limit.
+fix_code:
+  - language: yaml
+    label: "Authenticate to DockerHub to avoid rate limits on ubuntu-22.04"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-22.04
+          steps:
+            - name: Log in to DockerHub
+              uses: docker/login-action@v3
+              with:
+                username: ${{ secrets.DOCKERHUB_USERNAME }}
+                password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+            - name: Run tests with Postgres
+              run: |
+                docker run --rm -d -p 5432:5432 \
+                  -e POSTGRES_PASSWORD=test \
+                  postgres:15-alpine
+  - language: yaml
+    label: "Use GitHub Container Registry instead of DockerHub"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-22.04
+          permissions:
+            packages: read
+          steps:
+            - name: Log in to GHCR
+              uses: docker/login-action@v3
+              with:
+                registry: ghcr.io
+                username: ${{ github.actor }}
+                password: ${{ secrets.GITHUB_TOKEN }}
+
+            - name: Run service container from GHCR
+              run: docker run --rm ghcr.io/myorg/my-image:latest
+prevention:
+  - "Authenticate to DockerHub in all workflows that pull images on ubuntu-22.04 runners."
+  - "Consider migrating ubuntu-22.04 workflows to ubuntu-24.04 — it's the current default and avoids this issue."
+  - "Prefer GitHub Container Registry (ghcr.io) for your own images to eliminate DockerHub rate limits entirely."
+  - "Use `docker/login-action` as a standard first step in any workflow that involves Docker image pulls."
+  - "Monitor job durations after runner image updates — unexpected slowdowns often signal a caching change."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/13472"
+    label: "runner-images#13472 — ubuntu-22.04 pre-cached Docker images removal announcement"
+  - url: "https://github.com/actions/runner-images/issues/1445"
+    label: "runner-images#1445 — DockerHub pull rate limit discussion"
+  - url: "https://docs.docker.com/docker-hub/download-rate-limit/"
+    label: "DockerHub pull rate limits documentation"
+  - url: "https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry"
+    label: "Working with GitHub Container Registry (ghcr.io)"

package/errors/runner-environment/windows-latest-d-drive-removed.yml

@@ -0,0 +1,104 @@
+id: runner-environment-043
+title: "windows-latest Windows Server 2025 Runner Removed D: Drive — Paths Fail"
+category: runner-environment
+severity: error
+tags:
+  - windows
+  - runner-image
+  - d-drive
+  - path
+  - windows-server-2025
+  - breaking-change
+patterns:
+  - regex: "The system cannot find the path specified.*D:\\\\"
+    flags: "i"
+  - regex: "D:\\\\.*No such file or directory"
+    flags: "i"
+  - regex: "Path.*D:\\\\.*does not exist"
+    flags: "i"
+  - regex: "cannot find.*'D:\\\\|D:\\\\.*not found"
+    flags: "i"
+error_messages:
+  - "The system cannot find the path specified: 'D:\\a\\'"
+  - "D:\\a\\ : No such file or directory"
+  - "Cannot find path 'D:\\build' because it does not exist."
+  - "Error: ENOENT: no such file or directory, open 'D:\\tools\\...'"
+root_cause: |
+  The Windows Server 2025 runner image, which became the target of `windows-latest`
+  and `windows-2025` starting mid-2026, **removed the D: drive** that was present
+  on earlier Windows runner images (Windows Server 2019 and 2022).
+
+  On Windows Server 2019/2022 runners, the D: drive was a separate disk used for
+  temporary build storage and tools. Some workflows hardcoded paths like
+  `D:\a\`, `D:\tools\`, `D:\hostedtoolcache\`, or `D:\temp\` instead of using
+  environment variables like `${{ runner.tool_cache }}`, `$RUNNER_TOOL_CACHE`,
+  or workspace-relative paths.
+
+  On Windows Server 2025 runners, only the C: drive is available. Any workflow
+  step that writes to or reads from an absolute `D:\` path will immediately fail
+  with a path-not-found error, often as a confusing "system cannot find path" error
+  rather than a clear "D: drive missing" message.
+
+  Root issue thread: actions/runner-images#12416 (D: drive removal discussion)
+  and runner-images#12677 (windows-latest → Windows Server 2025 migration).
+fix: |
+  Replace all hardcoded `D:\` paths with environment variable references or
+  workspace-relative paths:
+
+  | Old (hardcoded D:) | New (portable)                          |
+  |--------------------|----------------------------------------|
+  | `D:\hostedtoolcache` | `${{ runner.tool_cache }}`          |
+  | `D:\a\${{ github.repository }}` | `${{ github.workspace }}`  |
+  | `D:\temp\`         | `${{ runner.temp }}`                   |
+  | `D:\tools\`        | Explicit installation to `C:\tools\`   |
+
+  For existing scripts that reference `D:\` directly, either:
+  1. Update all references to use RUNNER_TEMP, RUNNER_TOOL_CACHE, or GITHUB_WORKSPACE
+  2. Temporarily pin `runs-on: windows-2022` while you migrate
+fix_code:
+  - language: yaml
+    label: "Replace D:\\ paths with portable runner environment variables"
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest  # Works on Server 2025 (no D: drive)
+          steps:
+            - uses: actions/checkout@v4
+
+            # ❌ Broken: hardcoded D: path
+            # - run: Copy-Item -Path "D:\hostedtoolcache\node\20.0.0\x64\bin\node.exe" -Destination "${{ github.workspace }}"
+
+            # ✅ Fixed: use runner context variables
+            - name: Use portable paths
+              run: |
+                echo "Workspace: ${{ github.workspace }}"
+                echo "Tool cache: ${{ runner.tool_cache }}"
+                echo "Temp dir: ${{ runner.temp }}"
+                # C: drive is always available on all Windows runner images
+                $toolsDir = "C:\tools"
+                New-Item -ItemType Directory -Force -Path $toolsDir
+  - language: yaml
+    label: "Temporary rollback — pin to windows-2022 while migrating"
+    code: |
+      jobs:
+        build:
+          # Pin to windows-2022 (D: drive still present) while fixing hardcoded paths
+          runs-on: windows-2022
+          steps:
+            - uses: actions/checkout@v4
+            - run: msbuild MyProject.sln
+prevention:
+  - "Never hardcode `D:\\` paths in workflows or scripts — always use `${{ runner.tool_cache }}`, `${{ runner.temp }}`, `${{ github.workspace }}`, or `C:\\`-relative paths."
+  - "Audit workflows and called scripts for `D:\\` references before migrating to `windows-latest` (Windows Server 2025)."
+  - "Subscribe to actions/runner-images release announcements so runner image migrations do not catch you off-guard."
+  - "Use `windows-2022` as a temporary pin if immediate migration is not feasible; note that Server 2022 images have a defined EOL."
+  - "Test Windows workflows in a `windows-2025` matrix slot before the `windows-latest` migration window completes."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/12416"
+    label: "runner-images#12416 — D: drive removal discussion"
+  - url: "https://github.com/actions/runner-images/issues/12677"
+    label: "runner-images#12677 — windows-latest migration to Windows Server 2025"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables"
+    label: "GitHub Docs: Default environment variables (runner.tool_cache, runner.temp)"
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories"
+    label: "About GitHub-hosted runners — Windows Server 2025 specs"

package/errors/runner-environment/windows-msvc-ltcg-mixed-image-versions.yml

@@ -0,0 +1,112 @@
+id: runner-environment-036
+title: "Windows MSVC LTCG Linker Fails When Jobs in Same Run Receive Different Image Versions"
+category: runner-environment
+severity: error
+tags:
+  - windows
+  - msvc
+  - ltcg
+  - linker
+  - runner-image
+  - build
+  - vs2026
+patterns:
+  - regex: "C1900.*Il mismatch between 'P1' version.*and 'P2' version"
+    flags: "i"
+  - regex: "LNK1257.*code generation failed"
+    flags: "i"
+  - regex: "LNK2001.*unresolved external symbol __std_"
+    flags: "i"
+  - regex: "fatal error C1900"
+    flags: "i"
+error_messages:
+  - "EXEC : fatal error C1900: Il mismatch between 'P1' version '20251208' and 'P2' version '20250730'"
+  - "LINK : fatal error LNK1257: code generation failed"
+  - "skia.lib(...) : error LNK2001: unresolved external symbol __std_minmax_element_f_"
+  - "skia.lib(...) : error LNK2001: unresolved external symbol __std_max_element_2u"
+root_cause: |
+  GitHub Actions does not guarantee that all jobs within a single workflow run receive
+  the same concrete runner image version. When a runner image is being rolled out
+  (e.g., during a VS 2026 update or patch cycle), some jobs may be assigned to runners
+  with image version 20260510.103.1 while others receive 20260518.113.1 — even for
+  jobs with the same `runs-on: windows-2025-vs2026` label.
+
+  This becomes a hard build failure for workflows that use MSVC Link-Time Code
+  Generation (LTCG / /GL):
+  - Job A (build) compiles .obj and .lib files with /GL on image version X
+    → MSVC compiler emits Intermediate Language (IL) artifacts stamped with version X.
+  - Job B (link) downloads those artifacts and attempts to link them using /LTCG on
+    image version Y (a different MSVC toolset patch version).
+  - MSVC detects the IL version mismatch (C1900) and aborts: the IL produced by
+    one toolset cannot be consumed by a different toolset version.
+
+  The same failure can occur for any build pipeline that:
+  - Splits compilation and linking across separate jobs
+  - Uses artifact upload/download to pass compiled objects between jobs
+  - Relies on LTCG, MSVC STL internals, or other IL-sensitive optimizations
+
+  This is a known limitation of the GitHub Actions runner assignment model — image
+  rollouts are gradual across the runner pool, and job assignments are not pinned
+  to a specific image version within a run.
+
+  Source: actions/runner-images#14140
+fix: |
+  **Option 1 — Combine compile and link in a single job** so all MSVC operations
+  run on the same runner image. This eliminates the cross-image artifact transfer.
+
+  **Option 2 — Disable LTCG for CI builds** (/GL is a release optimization; most
+  CI builds only need it for final release binaries, not PRs or branch builds).
+
+  **Option 3 — Add MSVC toolset version check** in the link job to detect mismatches
+  before the link fails, and fail fast with a clear diagnostic message.
+
+  **Option 4 — Use a self-hosted runner** with a pinned image version for builds
+  that require LTCG across jobs.
+fix_code:
+  - language: yaml
+    label: "Combine compile and link in one job to avoid image mismatch"
+    code: |
+      jobs:
+        build-and-link:
+          runs-on: windows-2025-vs2026
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Configure CMake
+              run: cmake -B build -DCMAKE_BUILD_TYPE=Release
+
+            # Compile AND link in the same job — same image version guaranteed
+            - name: Build (compile + link)
+              run: cmake --build build --config Release
+  - language: yaml
+    label: "Disable LTCG on CI builds, enable only for release"
+    code: |
+      jobs:
+        build:
+          runs-on: windows-2025-vs2026
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build without LTCG (CI)
+              # Pass -DNO_LTCG=1 or equivalent CMake flag to disable /GL and /LTCG
+              # LTCG is only enabled in the separate release workflow
+              run: cmake -B build -DCMAKE_BUILD_TYPE=Release -DENABLE_LTCG=OFF
+              env:
+                # Alternatively: override CFLAGS/CXXFLAGS directly
+                CFLAGS: /O2     # Optimize without /GL
+                CXXFLAGS: /O2
+prevention:
+  - "Never split MSVC compilation and LTCG linking across separate jobs that upload/download artifacts."
+  - "Disable /GL (LTCG) in CI builds — reserve it for final release artifact builds on a single job."
+  - "Monitor runner image rollout announcements; if a new Windows image version is being deployed, LTCG cross-job builds are at risk during the rollout window."
+  - "Add a MSVC version check step at the start of link jobs to emit the toolset version to logs for post-failure diagnosis."
+  - "Use self-hosted runners with pinned image versions for release builds that require LTCG across jobs."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/14140"
+    label: "runner-images#14140 — MSVC LTCG linker failure from mixed image versions in same run"
+  - url: "https://learn.microsoft.com/en-us/cpp/build/reference/gl-whole-program-optimization"
+    label: "MSVC /GL (Whole Program Optimization) documentation"
+  - url: "https://learn.microsoft.com/en-us/cpp/build/reference/ltcg-link-time-code-generation"
+    label: "MSVC /LTCG (Link-Time Code Generation) documentation"
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners"
+    label: "About GitHub-hosted runners"

package/errors/runner-environment/windows-vs2026-cuda-host-compiler-unsupported.yml

@@ -0,0 +1,145 @@
+id: runner-environment-046
+title: "CUDA nvcc Rejects Visual Studio 2026 Host Compiler on windows-latest"
+category: runner-environment
+severity: error
+tags:
+  - windows
+  - windows-latest
+  - cuda
+  - nvcc
+  - visual-studio-2026
+  - vs2026
+  - runner-image
+  - breaking-change
+  - gpu
+patterns:
+  - regex: "unsupported Microsoft Visual Studio version.*Only the versions between 2019 and 2022"
+    flags: "i"
+  - regex: "fatal error C1189.*unsupported Microsoft Visual Studio version"
+    flags: "i"
+  - regex: "nvcc.*error.*host_config\\.h.*C1189"
+    flags: "i"
+  - regex: "CUDA.*requires Visual Studio.*2022|nvcc.*does not support.*Visual Studio 18"
+    flags: "i"
+  - regex: "error:\\s+--\\s+unsupported Microsoft Visual Studio version"
+    flags: "i"
+error_messages:
+  - "fatal error C1189: #error:  -- unsupported Microsoft Visual Studio version! Only the versions between 2019 and 2022 (inclusive) are supported!"
+  - "Error in C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v13.1\\include\\crt/host_config.h(164)"
+  - "nvcc fatal   : Host compiler targets unsupported OS."
+  - "nvcc error  : Failed to preprocess the host compiler properties."
+root_cause: |
+  GitHub Actions migrated `windows-latest` (and `windows-2025`) from Visual Studio 2022 to
+  Visual Studio 2026 (version 18.x) beginning June 8, 2026, completing by June 15, 2026.
+  Additionally, some users saw the switch as early as May 5, 2026 when `windows-2025`
+  started serving the `windows-2025-vs2026` image label prematurely (runner-images#14004).
+
+  CUDA toolkits up to and including CUDA 13.x hard-code supported Visual Studio version
+  ranges inside `<CUDA_ROOT>/include/crt/host_config.h`. The file checks the `_MSC_VER`
+  compiler macro and rejects any version outside the explicitly listed range. Visual Studio
+  2022 (MSVC 19.3x) is the last version supported by all CUDA releases through CUDA 13.x.
+  Visual Studio 2026 (MSVC 19.4x / VS version 18.x) falls outside these ranges and triggers
+  an immediate hard compiler error:
+
+    fatal error C1189: #error:  -- unsupported Microsoft Visual Studio version! Only the
+    versions between 2019 and 2022 (inclusive) are supported! The nvcc flag
+    '-allow-unsupported-compiler' can be used to override this version check; however,
+    using an unsupported host compiler may cause compilation failure or incorrect run time
+    execution. Use at your own risk.
+
+  The error fires at the preprocessing stage — before any CUDA code is compiled — so it
+  affects any project that invokes `nvcc`, regardless of the CUDA source code content.
+
+  Source: actions/runner-images#14017, runner-images#14004, NVIDIA CUDA Installation Guide
+fix: |
+  **Option 1 — Use `-allow-unsupported-compiler` flag** (quick unblock, use at own risk):
+  Adds a flag to nvcc that bypasses the version check. Works for many projects but NVIDIA
+  does not guarantee correctness with unsupported compilers.
+
+  **Option 2 — Pin to windows-2022** (safest immediate fix):
+  `windows-2022` still ships Visual Studio 2022. It is not yet deprecated.
+
+  **Option 3 — Upgrade to a CUDA version that supports VS 2026** (best long-term):
+  NVIDIA releases new CUDA toolkits that list VS 2026 in their supported compiler matrix.
+  Check the CUDA Toolkit Release Notes for the current supported VS version table.
+
+  **Option 4 — Use CMake's `CUDAARCHS` + VS2022 generator explicitly**:
+  If using CMake, pin the generator to `Visual Studio 17 2022` even on windows-latest by
+  specifying `-G "Visual Studio 17 2022"` in your cmake configure step. This forces CMake
+  to use the VS 2022 tools even if VS 2026 is the default.
+fix_code:
+  - language: yaml
+    label: "Pin to windows-2022 to avoid VS 2026 entirely"
+    code: |
+      jobs:
+        build-cuda:
+          runs-on: windows-2022   # VS 2022 — supported by CUDA up to 13.x
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build with CUDA
+              run: cmake --build . --config Release
+  - language: yaml
+    label: "Pass -allow-unsupported-compiler to nvcc (quick unblock)"
+    code: |
+      jobs:
+        build-cuda:
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Pass flag via CMake CUDA_NVCC_FLAGS
+            - name: Configure CMake
+              run: |
+                cmake -B build -DCMAKE_CUDA_FLAGS="-allow-unsupported-compiler"
+
+            - name: Build
+              run: cmake --build build --config Release
+  - language: yaml
+    label: "Force VS 2022 CMake generator on windows-latest (VS 2026 image)"
+    code: |
+      jobs:
+        build-cuda:
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Explicitly select VS 2022 generator even when VS 2026 is default
+            - name: Configure with VS 2022 generator
+              run: |
+                cmake -B build `
+                  -G "Visual Studio 17 2022" `
+                  -A x64
+
+            - name: Build
+              run: cmake --build build --config Release
+  - language: yaml
+    label: "Upgrade CUDA toolkit version that supports VS 2026"
+    code: |
+      jobs:
+        build-cuda:
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Install a CUDA version that explicitly supports VS 2026
+            # (check NVIDIA release notes for the current minimum supported version)
+            - name: Install CUDA Toolkit
+              uses: Jimver/cuda-toolkit@v0.2.21
+              with:
+                cuda: '12.8.0'   # Check if this version lists VS 2026 in its support matrix
+
+            - name: Build
+              run: cmake --build build --config Release
+prevention:
+  - "Never assume CUDA is forward-compatible with new Visual Studio versions — CUDA hard-codes supported MSVC version ranges."
+  - "Pin `runs-on: windows-2022` for CUDA workflows until the CUDA version you use explicitly lists VS 2026 as supported."
+  - "Subscribe to runner-images#14017 and similar announcements before the windows-latest label migration date."
+  - "Check the CUDA Toolkit Release Notes for your version's supported host compiler table before upgrading either Visual Studio or CUDA."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/14017"
+    label: "runner-images#14017: windows-latest will use VS 2026 image in June 2026"
+  - url: "https://github.com/actions/runner-images/issues/14004"
+    label: "runner-images#14004: windows-2025 serving VS 2026 image prematurely (May 2026)"
+  - url: "https://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/"
+    label: "NVIDIA CUDA Installation Guide — supported Visual Studio versions"