This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new d1d54fb835b2 CAMEL-24829: WebsiteInstallerFixture - isolate
PSModulePath for install.ps1 on Windows
d1d54fb835b2 is described below
commit d1d54fb835b2e247f546cc6d29be23bad161e469
Author: Adriano Machado <[email protected]>
AuthorDate: Sat Sep 19 07:17:58 2026 -0400
CAMEL-24829: WebsiteInstallerFixture - isolate PSModulePath for install.ps1
on Windows
Follow-up to CAMEL-24485 (#26568). The WindowsPowerShell suite in
windows-validator still took ~1200s, with 99% of it in the 46 install.ps1
launches (median 25.4s each).
WebsiteInstallerFixture clears the child environment, and with PSModulePath
unset (or pointing at Windows PowerShell's built-in module directory) the
first cmdlet call in install.ps1 spends ~18s on windows-latest scanning
Program Files\WindowsPowerShell\Modules (AWSPowerShell, Microsoft.Graph,
SqlServer). Pointing PSModulePath at the isolated per-test home's own empty
user module directory brings that call down to 0.2s while Windows
PowerShell still finds its built-in cmdlets, and keeps the suite
independent of whatever modules the runner has installed.
Also drops the PSModuleAnalysisCachePath setting from #26568, which the
bisect showed has no effect.
Result: the WindowsPowerShell suite runs in 90s (was 901-1206s), install.ps1
launches take a median of 1.96s (was 19.5-25.4s), and the windows-validator
job finishes in ~5 minutes. Production is unaffected: SelfUpdateCommand only
clears the installer environment under its test-only override.
Closes #26609
Co-authored-by: Claude Code <[email protected]>
---
.../dsl/jbang/launcher/WebsiteInstallerFixture.java | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
a/dsl/camel-jbang/camel-launcher/src/test/java/org/apache/camel/dsl/jbang/launcher/WebsiteInstallerFixture.java
b/dsl/camel-jbang/camel-launcher/src/test/java/org/apache/camel/dsl/jbang/launcher/WebsiteInstallerFixture.java
index 996e2eddf74f..74a4729567f1 100644
---
a/dsl/camel-jbang/camel-launcher/src/test/java/org/apache/camel/dsl/jbang/launcher/WebsiteInstallerFixture.java
+++
b/dsl/camel-jbang/camel-launcher/src/test/java/org/apache/camel/dsl/jbang/launcher/WebsiteInstallerFixture.java
@@ -64,8 +64,6 @@ final class WebsiteInstallerFixture implements AutoCloseable {
private static final String KEY_ALIAS = "camel-installer-test";
private static final String DEFAULT_BASE_VERSION = "9.9.9";
private static final Duration PROCESS_TIMEOUT = Duration.ofSeconds(60);
- private static final Path POWERSHELL_MODULE_ANALYSIS_CACHE
- = Path.of("target", "powershell",
"ModuleAnalysisCache").toAbsolutePath();
record Result(int exit, String stdout, String stderr) {
}
@@ -457,13 +455,18 @@ final class WebsiteInstallerFixture implements
AutoCloseable {
pb.environment().put(name, value);
}
}
- // PowerShell keeps its module analysis cache under LOCALAPPDATA,
which every test points at a
- // fresh home, so each powershell.exe launch would rebuild it from
scratch when auto-loading
- // Expand-Archive / Get-FileHash. Share one cache file across the
whole test run instead.
-
Files.createDirectories(POWERSHELL_MODULE_ANALYSIS_CACHE.getParent());
- pb.environment().put("PSModuleAnalysisCachePath",
POWERSHELL_MODULE_ANALYSIS_CACHE.toString());
}
pb.environment().putAll(env);
+ String userProfile = env.get("USERPROFILE");
+ if (FakeJava.WINDOWS && userProfile != null) {
+ // Point PSModulePath at the isolated home's own (empty) user
module directory. When PSModulePath
+ // is unset, or lists Windows PowerShell's built-in module
directory, the first cmdlet call
+ // (install.ps1's Join-Path on line 29) spends ~18s on
windows-latest, whose
+ // Program Files\WindowsPowerShell\Modules holds AWSPowerShell,
Microsoft.Graph and SqlServer; that
+ // made every install.ps1 run in this suite cost ~20s. With only
an unrelated directory listed, the
+ // same call takes 0.2s and Windows PowerShell still finds its
built-in cmdlets.
+ pb.environment().put("PSModulePath", Path.of(userProfile,
"Documents", "WindowsPowerShell", "Modules").toString());
+ }
String home = env.get("HOME");
if (home != null && Files.isDirectory(Path.of(home))) {
// Any accidental relative-path side effect lands in the isolated
test HOME rather than
