From e39dbf73b818bb8f5a464020fd27d3c8e750fba7 Mon Sep 17 00:00:00 2001 From: Hector Flores Date: Sat, 13 Jun 2026 11:08:25 -0500 Subject: [PATCH] feat: add 3 new error entries (runner-environment x2, silent-failures x1) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- ...urerm-azure-powershell-modules-removed.yml | 96 +++++++++++++++ ...s-2025-nsis-removed-makensis-not-found.yml | 90 ++++++++++++++ errors/silent-failures/sf-233.yml | 115 ++++++++++++++++++ 3 files changed, 301 insertions(+) create mode 100644 errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml create mode 100644 errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml create mode 100644 errors/silent-failures/sf-233.yml diff --git a/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml b/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml new file mode 100644 index 0000000..da2e613 --- /dev/null +++ b/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml @@ -0,0 +1,96 @@ +id: re-499 +title: "Windows Server 2025: AzureRM and Azure PowerShell modules removed from default install" +category: runner-environment +severity: error +tags: + - windows-2025 + - windows-latest + - powershell + - azurerm + - azure-module + - runner-image-update +patterns: + - regex: 'Import-Module\s*:\s*The specified module\s+[''"]?Azure(?:RM)?[''"]?\s+was not loaded because no valid module file was found' + flags: i + - regex: 'PackageManagement\s*:\s*No match was found for the specified search criteria and module name\s+[''"]?Azure(?:RM)?[''"]?' + flags: i + - regex: 'The term\s+[''"]?(?:Get|Set|New|Remove|Connect)-Azure(?:RM)?[A-Za-z]+[''"]?\s+is not recognized' + flags: i +error_messages: + - "Import-Module : The specified module 'AzureRM' was not loaded because no valid module file was found in any module directory." + - "Import-Module : The specified module 'Azure' was not loaded because no valid module file was found in any module directory." + - "PackageManagement : No match was found for the specified search criteria and module name 'AzureRM'." + - "The term 'Login-AzureRmAccount' is not recognized as the name of a cmdlet, function, script file, or operable program." + - "The term 'Connect-AzureRmAccount' is not recognized as the name of a cmdlet, function, script file, or operable program." +root_cause: | + When `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 (rolled out September 2025), + GitHub removed the legacy `AzureRM` and `Azure` PowerShell modules from the pre-installed software list on the + Windows Server 2025 runner image. These modules were deprecated by Microsoft in favour of the `Az` PowerShell + module (introduced in December 2018) and their inclusion was dropped from windows-2025 images as part of the + disk-space reduction effort documented in actions/runner-images#12677. + + Workflows that call legacy cmdlets such as `Login-AzureRmAccount`, `Get-AzureRmResource`, `New-AzureRmResourceGroup`, + or that run `Import-Module AzureRM` / `Import-Module Azure` without first installing the modules at runtime will fail + immediately with a "module not found" error on `windows-latest` (windows-2025) runners. + + The `Az` module (modern replacement) is pre-installed and fully functional on both windows-2022 and windows-2025 + images. `Az` cmdlets follow the naming convention `*-Az*` (e.g. `Connect-AzAccount`, `Get-AzResource`). +fix: | + Migrate from the legacy `AzureRM`/`Azure` modules to the modern `Az` PowerShell module. The `Az` module ships + pre-installed on all supported runner images and is fully supported. + + If you cannot migrate immediately, install `AzureRM` at runtime as a workaround (not recommended for new workflows): + + ```powershell + Install-Module -Name AzureRM -Repository PSGallery -Force -AllowClobber + ``` + + The recommended long-term fix is to update all cmdlets: + - `Login-AzureRmAccount` → `Connect-AzAccount` + - `Get-AzureRmResource` → `Get-AzResource` + - `New-AzureRmResourceGroup` → `New-AzResourceGroup` + - `Get-AzureRmSubscription` → `Get-AzSubscription` + (Full migration guide: https://docs.microsoft.com/en-us/powershell/azure/migrate-from-azurerm-to-az) +fix_code: + - language: yaml + label: "Migrate to Az module (windows-2025 compatible)" + code: | + jobs: + deploy: + runs-on: windows-latest # Now windows-2025; Az is pre-installed + steps: + - name: Login to Azure + uses: azure/login@v2 + with: + creds: ${{ secrets.AZURE_CREDENTIALS }} + + - name: Get resource group + shell: pwsh + run: | + # Az module (pre-installed on windows-2025) + Get-AzResourceGroup -Name "my-rg" + # NOT: Get-AzureRmResourceGroup (removed on windows-2025) + - language: yaml + label: "Runtime install workaround (migration not yet complete)" + code: | + jobs: + deploy: + runs-on: windows-latest + steps: + - name: Install AzureRM module at runtime + shell: pwsh + run: | + Install-Module -Name AzureRM -Repository PSGallery -Force -AllowClobber -Scope CurrentUser + Import-Module AzureRM +prevention: + - "Use the modern `Az` PowerShell module (`*-Az*` cmdlets) instead of the deprecated `AzureRM`/`Azure` modules." + - "Pin `runs-on: windows-2022` temporarily if migration to Az is not yet possible, then schedule migration." + - "Prefer the `azure/login@v2` GitHub Action with `Az` for Azure authentication in CI — avoids module management entirely." + - "Run `Get-Module -ListAvailable Az*` in your workflow to verify Az module availability and version on the runner." +docs: + - url: "https://github.com/actions/runner-images/issues/12677" + label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (breaking changes table)" + - url: "https://docs.microsoft.com/en-us/powershell/azure/migrate-from-azurerm-to-az" + label: "Microsoft: Migrate Azure PowerShell from AzureRM to Az" + - url: "https://docs.microsoft.com/en-us/powershell/azure/install-az-ps" + label: "Microsoft: Install the Azure Az PowerShell module" diff --git a/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml b/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml new file mode 100644 index 0000000..99b1fa4 --- /dev/null +++ b/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml @@ -0,0 +1,90 @@ +id: re-500 +title: "Windows Server 2025: NSIS removed — makensis command not found" +category: runner-environment +severity: error +tags: + - windows-2025 + - windows-latest + - nsis + - installer + - runner-image-update + - makensis +patterns: + - regex: '''makensis''\s+is not recognized as an internal or external command' + flags: i + - regex: 'makensis\s*:\s*The term\s+.+\s+is not recognized as the name of a cmdlet' + flags: i + - regex: "makensis['\"]?\\s*:?\\s*command not found" + flags: i + - regex: 'Error\s*:\s*Could not find NSIS' + flags: i +error_messages: + - "'makensis' is not recognized as an internal or external command, operable program or batch file." + - "makensis : The term 'makensis' is not recognized as the name of a cmdlet, function, script file, or operable program." + - "Error: Could not find NSIS. Please install NSIS and make sure makensis is in your PATH." +root_cause: | + NSIS (Nullsoft Scriptable Install System) was removed from the Windows Server 2025 runner image when + `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 in September 2025 + (actions/runner-images#12677). NSIS was pre-installed on windows-2019 and windows-2022 images but was + excluded from windows-2025 due to low usage and disk-space constraints. + + Workflows that build Windows installers using NSIS scripts (`.nsi` files) via `makensis` will fail immediately + with a "command not found" error on `windows-latest` (windows-2025) runners. This affects any workflow that: + - Calls `makensis` directly in a `run:` step + - Uses build tools that invoke `makensis` internally (e.g. electron-builder, cmake-nsis, create-react-app + Windows installer scripts) + - References `$env:NSIS_DIR` or hardcodes `C:\Program Files (x86)\NSIS\makensis.exe` +fix: | + Install NSIS at runtime using Chocolatey (pre-installed on all Windows runner images): + + ```yaml + - name: Install NSIS + run: choco install nsis --yes + shell: pwsh + ``` + + Alternatively, pin your workflow to `windows-2022` if NSIS is a critical dependency and runtime + installation adds too much overhead, then plan a migration to WiX Toolset or MSIX packaging. +fix_code: + - language: yaml + label: "Install NSIS at runtime via Chocolatey" + code: | + jobs: + build-installer: + runs-on: windows-latest # windows-2025: NSIS not pre-installed + steps: + - uses: actions/checkout@v4 + + - name: Install NSIS + shell: pwsh + run: choco install nsis --yes --no-progress + + - name: Build installer + shell: pwsh + run: | + $makensis = "C:\Program Files (x86)\NSIS\makensis.exe" + & $makensis /V4 installer.nsi + - language: yaml + label: "Pin to windows-2022 (NSIS pre-installed) as temporary workaround" + code: | + jobs: + build-installer: + runs-on: windows-2022 # NSIS pre-installed; migrate to windows-2025 + choco install + steps: + - uses: actions/checkout@v4 + - name: Build installer + run: makensis /V4 installer.nsi +prevention: + - "Install NSIS explicitly via `choco install nsis` rather than relying on runner image pre-installation." + - "Use `actions/cache` to cache the Chocolatey package downloads and avoid repeated install overhead." + - "Consider migrating to WiX Toolset (wix.io) or MSIX packaging for modern Windows installer builds — both are pre-installed on windows-2025." + - "Pin `runs-on: windows-2022` in the short term if runtime installation is not feasible, with a TODO to migrate." +docs: + - url: "https://github.com/actions/runner-images/issues/12677" + label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (NSIS removed)" + - url: "https://github.com/actions/runner-images/issues/11754" + label: "actions/runner-images#11754 — Request to add NSIS to windows-2025 image" + - url: "https://nsis.sourceforge.io/Main_Page" + label: "NSIS — Nullsoft Scriptable Install System" + - url: "https://community.chocolatey.org/packages/nsis" + label: "Chocolatey: NSIS package" diff --git a/errors/silent-failures/sf-233.yml b/errors/silent-failures/sf-233.yml new file mode 100644 index 0000000..f6b3c1a --- /dev/null +++ b/errors/silent-failures/sf-233.yml @@ -0,0 +1,115 @@ +id: sf-233 +title: "Windows Server 2025: default Java silently changed from 8 to 17, breaking Maven/Gradle builds" +category: silent-failures +severity: silent-failure +tags: + - windows-2025 + - windows-latest + - java + - maven + - gradle + - java-version + - runner-image-update +patterns: + - regex: 'Source option \d+ is no longer supported\. Use \d+ or later' + flags: i + - regex: 'error:\s+source release \d+ requires target release \d+' + flags: i + - regex: 'InaccessibleObjectException.*Unable to make.*accessible.*module java\.base' + flags: i + - regex: 'Unsupported class file major version \d+' + flags: i + - regex: 'JAVA_HOME\s*=\s*C:\\Program Files\\(?:Eclipse Adoptium|Microsoft)\\jdk-17' + flags: i +error_messages: + - "error: Source option 8 is no longer supported. Use 11 or later." + - "error: source release 8 requires target release 8" + - "java.lang.reflect.InaccessibleObjectException: Unable to make field ... accessible: module java.base does not 'opens java.lang' to unnamed module" + - "Unsupported class file major version 61" + - "[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!" +root_cause: | + When `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 (September 2025, + actions/runner-images#12677), the default pre-installed Java version changed from **Java 8 (JDK 8)** + to **Java 17 (JDK 17)**. On windows-2022, `java -version` returned a 1.8.x JDK. On windows-2025, + `java -version` returns a 17.x JDK. + + This is a silent failure because: + 1. Workflows that do NOT use `actions/setup-java` and rely on the system Java receive a different runtime + version without any explicit error or warning in the workflow log about the version change. + 2. Maven or Gradle builds configured with `1.8/1.8` in pom.xml may + continue to compile (Java 17 supports `--release 8`) but hit runtime failures when code uses + reflection patterns that Java 17's strong encapsulation (JEP 396, JEP 403) now restricts. + 3. Projects using Lombok, certain Spring Boot versions, JPA/Hibernate older versions, or AspectJ may + fail or produce different behavior under Java 17 strong encapsulation. + 4. Hardcoded `JAVA_HOME` paths pointing to a JDK 8 install directory will break silently when the + path no longer exists on windows-2025. + + This does NOT affect workflows that explicitly use `actions/setup-java` with a `java-version:` input, + as that action installs and pins the requested version regardless of runner image defaults. +fix: | + Always use `actions/setup-java` with an explicit `java-version:` to avoid dependence on the runner image + default Java version. This is the recommended practice regardless of runner OS or image version. + + If you need to stay on Java 8: + ```yaml + - uses: actions/setup-java@v4 + with: + distribution: temurin + java-version: '8' + ``` + + If migrating to Java 17 (recommended), audit your build for: + - Reflective access warnings/errors (add `--add-opens` JVM flags if needed) + - Outdated Lombok version (upgrade to 1.18.22+) + - Spring Boot 2.x reflection issues (upgrade to 2.6+ or 3.x for Java 17 support) +fix_code: + - language: yaml + label: "Pin Java version explicitly with actions/setup-java (prevents silent version drift)" + code: | + jobs: + build: + runs-on: windows-latest # windows-2025: default Java is now 17, not 8 + steps: + - uses: actions/checkout@v4 + + - name: Set up Java 17 + uses: actions/setup-java@v4 + with: + distribution: temurin + java-version: '17' + cache: maven # or 'gradle' + + - name: Build with Maven + run: mvn -B package --file pom.xml + - language: yaml + label: "Pin to Java 8 explicitly if legacy compatibility required" + code: | + jobs: + build: + runs-on: windows-latest + steps: + - uses: actions/checkout@v4 + + - name: Set up Java 8 + uses: actions/setup-java@v4 + with: + distribution: temurin + java-version: '8' + cache: gradle + + - name: Build with Gradle + run: ./gradlew build +prevention: + - "Always specify `java-version:` in `actions/setup-java` — never rely on the runner's system Java." + - "Add `actions/setup-java` as a required step in all Java workflow templates to prevent version drift." + - "Set `fail-fast: true` in your matrix to surface Java version incompatibilities immediately." + - "Use `.mvn/jvm.config` or `gradle.properties` to enforce the expected Java version at the build tool level." +docs: + - url: "https://github.com/actions/runner-images/issues/12677" + label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (Java default 8→17)" + - url: "https://github.com/actions/setup-java" + label: "actions/setup-java — Install and configure a specific Java version" + - url: "https://openjdk.org/jeps/403" + label: "JEP 403: Strongly Encapsulate JDK Internals (Java 17)" + - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-software" + label: "GitHub Docs: Supported software on GitHub-hosted runners"