ammachado opened a new pull request, #26568: URL: https://github.com/apache/camel/pull/26568
## Description Fixes [CAMEL-24485](https://issues.apache.org/jira/browse/CAMEL-24485): the `windows-validator` job of the *Package-native validation* workflow is very unstable. ### Root cause Across the 62 runs of the workflow since it was added (2026-07-15 to 2026-09-17), `windows-validator` failed in **33 of 54** completed runs. By failure signature: | Failure | Count | |---|---| | Surefire fork timeout in "Run Windows installer unit tests" | **19** | | `camel-buildtools:*-SNAPSHOT` not found in "Install camel-repackager-maven-plugin" (also hits the POSIX legs; out of scope here) | 7 | | Real test failures | 3 | | Early July setup breakage, since fixed | 4 | The `java.net.SocketException: Connection reset` quoted in the ticket is not a network problem. It is the Develocity capture thread losing its socket when surefire kills the forked JVM. The suite is not hanging, it is slow. `WebsiteInstallTest$WindowsPowerShell` (38 tests) took **626s to 1198s in the runs that passed**, and camel-launcher sets `camel.surefire.forkTimeout=1200`. 8 of the 21 passing runs finished less than 10 seconds before they would have been killed. There is no trend over time and the image (`windows-2025`) did not change, so the failures are just the slow end of the same distribution. ### Changes 1. **Fork timeout (stops the red):** the Windows test step passes `-Dcamel.surefire.forkTimeout=2700`, and the job gets `timeout-minutes: 60` so a genuine hang still fails well below GitHub's 6h default. Passing jobs took up to about 25 minutes end to end. I checked with `help:effective-pom` that the CLI property overrides the pom value (1200 → 2700). 2. **Measurement:** - `WebsiteInstallerFixture` prints one `[WebsiteInstallerFixture] <ms>: <command>` line per spawned process. Surefire streams test stdout to the build log live, so the timings survive a fork kill, where no XML report is written. - The job uploads `target/surefire-reports` (`if: always()`, 7-day retention). 3. **Speed-up attempts (need measuring on this PR's run):** - Every test points `LOCALAPPDATA` at a new, empty home, so each `powershell.exe` launch probably rebuilds its module analysis cache when auto-loading `Expand-Archive` / `Get-FileHash`. The fixture now sets `PSModuleAnalysisCachePath` to one shared file under `target/`. - The fixture passes `TEMP`/`TMP` through, so the C# compile that `install.ps1`'s `Add-Type` runs on every launch no longer writes into the per-test home. `install.ps1` itself never uses the temp directory. 4. **Bounded helper processes:** several helpers called `readAllBytes()` before `waitFor(30, SECONDS)`. The read blocks until every holder of the pipe closes it, so the timeout never applied. The POSIX `assertVersionInstalled` used `waitFor()` with no timeout at all. The bounded runner that `fixture.run()` already had is now `WebsiteInstallerFixture.execute(ProcessBuilder)`, and all 9 helper call sites use it. A helper that times out now fails the test instead of carrying on. ### Testing - macOS, locally: `WebsiteInstallTest` has 0 failures and 0 errors; all 37 POSIX tests pass, and the 11 reported skips are Windows-only tests. That exercises the refactored `run()` / `execute()` path, and the timing lines appear in the console. `WebsiteInstallerFixtureTest` passes 5/5. - **Not verified locally:** the Windows code paths, and whether Windows PowerShell 5.1 honors `PSModuleAnalysisCachePath` (the Microsoft docs I found cover 7.x). If 5.1 ignores it, nothing breaks; there is just no speed-up. This PR's own `windows-validator` run is the first measurement. - `SelfUpdateIntegrationTest` fails 6 of 8 tests locally ("unable to determine how the Camel CLI was installed"). The same 6 fail on unmodified `main`, and the test does not call any code touched here. Opened as a draft until the Windows run on this PR produces timings. 🤖 Generated with [Claude Code](https://claude.com/claude-code) on behalf of Adriano Machado (@ammachado) _This was generated by an AI agent and may contain inaccuracies. Please verify before relying on it._ -- 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]
