slachiewicz opened a new pull request, #274: URL: https://github.com/apache/maven-gh-actions-shared/pull/274
## Problem Every Windows job using `install-gpg: true` currently fails signing (see e.g. [maven-gpg-plugin Verify runs](https://github.com/apache/maven-gpg-plugin/actions/runs/29223244178/job/86733435698) — failing on master and every PR): ``` gpg: keyblock resource '/d/a/.../target/it/no-main-artifact/D:\\a\\...\\target\\test-classes\\gnupg/pubring.kbx': No such file or directory gpg: signing failed: No secret key ``` ## Root cause Chocolatey now installs **Gpg4win 5.x, which is 64-bit** and deploys GnuPG to `C:\Program Files\GnuPG` — the install log shows `Deployed to 'C:\Program Files\Gpg4win\..\GnuPG'`. The workflow's hardcoded PATH entry `C:\Program Files (x86)\Gpg4win\..\GnuPG\bin` matches the old 32-bit Gpg4win 4.x layout and no longer exists. As a result the freshly installed native GnuPG never lands on PATH, and `gpg` resolves to the MSYS build bundled with Git for Windows on the runner image (visible in the *Check GnuPG* step output: `Home: /c/Users/runneradmin/.gnupg`). MSYS gpg interprets Windows-style absolute paths passed via `--homedir` (`D:\a\...`) as *relative* POSIX paths and prepends the cwd, so keyrings are never found and all signing integration tests fail. ## Fix After `choco install gpg4win`, add whichever GnuPG bin directory actually exists to `GITHUB_PATH`, covering both the 4.x (`Program Files (x86)`) and 5.x (`Program Files`) layouts. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
