From 6c86e0b514dc56c2bd6c56d24f679329f66062f0 Mon Sep 17 00:00:00 2001 From: Thiago Alves Date: Mon, 8 Jun 2026 17:10:47 -0400 Subject: [PATCH 1/3] ci(release): pin both Windows jobs to windows-2025 (avoid VS 2026 maxBuffer bug) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v4.2.2's release run failed only on the Windows-ARM64 job with: gyp ERR! find VS Failure details: RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER] Error: Could not find any Visual Studio installation to use node-gyp failed to rebuild '@serialport/bindings-cpp' Direct comparison of runner images between releases: v4.2.1 (Jun 7, SUCCESS): Image: windows-2025 (VS 2022) v4.2.2 (Jun 8, FAILURE): Image: windows-2025-vs2026 (VS 2026) Same Windows Server 2025 OS, different Visual Studio version. `windows-latest` rotated forward to the `windows-2025-vs2026` image variant on Jun 8. VS 2026's `vswhere`/PowerShell enumeration emits enough metadata that the child_process stdout read in node-gyp's VS-finder overflows its 200 KB default buffer with `RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]`. node-gyp then reports "Could not find any Visual Studio installation," even though VS 2026 is fully installed on the runner. The ARM64 cross-compile of `@serialport/bindings-cpp` is the only path that hits this in the current build — Windows-x64 succeeded on the same v4.2.2 run because its native (non-cross-compile) build invokes a simpler node-gyp code path that doesn't enumerate VS the same way. Re-running the failed Win-ARM64 job reproduces deterministically; not a flake. This commit pins BOTH Windows jobs to `windows-2025` (the image that produced v4.2.0 / v4.2.1 successfully). Defensive: the Win-x64 job worked on `windows-latest = windows-2025-vs2026` today but the underlying VS 2026 maxBuffer issue could trip it on a future runner rotation (a fresh node-gyp/electron-builder release, a different native module, etc.). Pinning both today is cheaper than debugging the same class of failure again in a few months. When node-gyp / electron-builder ship a fix for the VS 2026 maxBuffer issue we can revert both to `windows-latest`. The tag `v4.2.2` will need to be re-cut to a commit that includes this workflow file — release workflow files are resolved at the tag's commit, so re-running the existing failed workflow would use the same (broken) workflow definition. Plan: land this on main, force-update v4.2.2 to the new merge commit, push the tag. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/release.yml | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 5ba5f18db..69aa89de7 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -124,7 +124,13 @@ jobs: # Windows Build - x64 # ============================================================================= build-windows-x64: - runs-on: windows-latest + # Pinned alongside build-windows-arm64 (see the comment block on + # that job for the full story). The Win-x64 build succeeded on + # `windows-latest = windows-2025-vs2026` for v4.2.2, but the + # underlying VS 2026 maxBuffer issue could trip x64 too on a + # future runner rotation. Pinning both today is cheaper than + # debugging the same class of failure again in a few months. + runs-on: windows-2025 steps: - name: Checkout repository uses: actions/checkout@v4 @@ -186,7 +192,22 @@ jobs: # Windows Build - ARM64 # ============================================================================= build-windows-arm64: - runs-on: windows-latest + # Pin to windows-2025 (NOT windows-latest): `windows-latest` + # rotated to the `windows-2025-vs2026` image variant between the + # v4.2.1 (Jun 7) and v4.2.2 (Jun 8) release runs. v4.2.1's + # successful build ran on the base `windows-2025` image (VS 2022 + # default); v4.2.2's failed build ran on `windows-2025-vs2026` + # (Visual Studio 2026). VS 2026's `vswhere`/PowerShell + # enumeration emits enough metadata that node-gyp's child_process + # stdout read overflows with `RangeError + # [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]` — node-gyp then reports + # "Could not find any Visual Studio installation to use" and the + # ARM64 cross-compile of `@serialport/bindings-cpp` fails. + # Explicit pin to `windows-2025` (VS 2022 default) restores the + # environment that produced v4.2.0 / v4.2.1. When node-gyp / + # electron-builder ship a fix for the VS 2026 maxBuffer issue + # we can revert to `windows-latest`. + runs-on: windows-2025 steps: - name: Checkout repository uses: actions/checkout@v4 From 35d8b901731610526c9c28a004ad4d6a8e769791 Mon Sep 17 00:00:00 2001 From: Thiago Alves Date: Mon, 8 Jun 2026 18:07:34 -0400 Subject: [PATCH 2/3] ci(release): pin Windows runners to windows-2022 (windows-2025 label no longer means VS 2022) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous pin to `windows-2025` did not help — GitHub has rebound the `windows-2025` label to the `win25-vs2026` runner-images branch (VS 2026), same as `windows-latest`. Verified by an explicit `runs-on: windows-2025` resolving to `Image: windows-2025-vs2026` in the v4.2.2 re-cut release run and failing identically with the same maxBuffer error. v4.2.1's successful build ran on `Image: windows-2025` AT A TIME when that label pointed at the `win25` branch (with VS 2022). That branch is no longer reachable via a runner label — only `windows-2022` (Windows Server 2022 + VS 2022) still ships VS 2022 on a GitHub-hosted image. The pin moves both Windows jobs to `windows-2022`. This is a more conservative environment (older Windows OS too, not just older VS) but it's the only GitHub-supported label that avoids VS 2026's `vswhere`/PowerShell-output maxBuffer overflow on node-gyp's VS finder. When node-gyp / electron-builder ship a fix for the VS 2026 issue we can revert to `windows-latest`. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/release.yml | 37 ++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 69aa89de7..c97ef643d 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -130,7 +130,7 @@ jobs: # underlying VS 2026 maxBuffer issue could trip x64 too on a # future runner rotation. Pinning both today is cheaper than # debugging the same class of failure again in a few months. - runs-on: windows-2025 + runs-on: windows-2022 steps: - name: Checkout repository uses: actions/checkout@v4 @@ -192,22 +192,27 @@ jobs: # Windows Build - ARM64 # ============================================================================= build-windows-arm64: - # Pin to windows-2025 (NOT windows-latest): `windows-latest` - # rotated to the `windows-2025-vs2026` image variant between the - # v4.2.1 (Jun 7) and v4.2.2 (Jun 8) release runs. v4.2.1's - # successful build ran on the base `windows-2025` image (VS 2022 - # default); v4.2.2's failed build ran on `windows-2025-vs2026` - # (Visual Studio 2026). VS 2026's `vswhere`/PowerShell - # enumeration emits enough metadata that node-gyp's child_process - # stdout read overflows with `RangeError + # Pin to windows-2022 (the only label that still gets VS 2022): + # `windows-latest` rotated to the VS 2026 variant on Jun 8 and + # broke this job. v4.2.1 (Jun 7) ran on `Image: windows-2025` + # which AT THE TIME used the `win25` runner-images branch with + # VS 2022. GitHub has since re-bound the `windows-2025` label + # to the `win25-vs2026` branch (VS 2026) — verified by an + # explicit `runs-on: windows-2025` resolving to `Image: + # windows-2025-vs2026` and failing identically. So `windows- + # 2025` is no longer a working label for our purposes; + # `windows-2022` (Windows Server 2022 + VS 2022) is the only + # remaining GitHub-hosted image that ships VS 2022. + # + # The failure mode: VS 2026's `vswhere`/PowerShell enumeration + # emits enough metadata that node-gyp's child_process stdout + # read overflows with `RangeError # [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]` — node-gyp then reports - # "Could not find any Visual Studio installation to use" and the - # ARM64 cross-compile of `@serialport/bindings-cpp` fails. - # Explicit pin to `windows-2025` (VS 2022 default) restores the - # environment that produced v4.2.0 / v4.2.1. When node-gyp / - # electron-builder ship a fix for the VS 2026 maxBuffer issue - # we can revert to `windows-latest`. - runs-on: windows-2025 + # "Could not find any Visual Studio installation to use" and + # the ARM64 cross-compile of `@serialport/bindings-cpp` fails. + # When node-gyp / electron-builder ship a fix we can revert to + # `windows-latest`. + runs-on: windows-2022 steps: - name: Checkout repository uses: actions/checkout@v4 From ab26d2576d03223888450fce3787f90b520eeb4f Mon Sep 17 00:00:00 2001 From: Thiago Alves Date: Tue, 11 Aug 2026 15:30:43 -0400 Subject: [PATCH 3/3] chore(release): bump version to 4.2.11 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Carried into the release PR itself so #1006 promotes the correct version to `main`, instead of needing a second PR after the fact. `APP_VERSION` is the single source of truth the About modal renders, and is byte-compared against openplc-web by the mirror gate — the identical edit lands there in Autonomy-Logic/openplc-web#667. `package.json.version` is what electron-builder stamps on the desktop binary and what the `v4.2.11` tag must match, so it is kept equal. Shipping only the package.json half is what left About showing 4.2.6 on the 4.2.7 and 4.2.8 releases. Co-Authored-By: Claude Opus 5 (1M context) --- package.json | 2 +- src/frontend/data/constants/app-version.ts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/package.json b/package.json index 8a90807d6..d3a908a27 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "open-plc-editor", "description": "OpenPLC Editor - IDE capable of creating programs for the OpenPLC Runtime", - "version": "4.2.10", + "version": "4.2.11", "license": "GPL-3.0", "author": { "name": "Autonomy Logic" diff --git a/src/frontend/data/constants/app-version.ts b/src/frontend/data/constants/app-version.ts index 3b99e5528..79ed6c0ac 100644 --- a/src/frontend/data/constants/app-version.ts +++ b/src/frontend/data/constants/app-version.ts @@ -18,4 +18,4 @@ * compares a per-deploy `BUILD_ID` (git commit SHA), not this version, so a * stale tab is detected on every deploy even without a version bump. */ -export const APP_VERSION = '4.2.10' +export const APP_VERSION = '4.2.11'