-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Windows builds #4447
Enable Windows builds #4447
Conversation
(cherry picked from commit 29848fa)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am looking at when the 11.0.6 release of the base image will be available, then we can hopefully restart doing the jdk11 builds, but this looks good to me for what we can currently do.
As in #4178, I do not actually care that much about this—testing Linux/8 + Windows/8 + Linux/11 is probably adequate coverage; the main problem I was hitting seems to be a lack of memory for the Windows/8 builds, which I cannot work around at this level. (If we switched our build environment to Kubernetes then I could use a |
Getting the same cleanup errors in |
The others are problems in |
@slonopotamus @jtnord FYI |
#4382 is also related |
Jenkinsfile
Outdated
sh 'git add . && git diff --exit-code HEAD' | ||
} else { | ||
bat mvnCmd | ||
// TODO tool 'mvn' is still an old version without -ntp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eek... maybe ToolInstallations
would help here (anyway still waiting for INFRA-2375 / INFRA-2080 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah just waiting for 2080.
<id>all-tests</id> | ||
<activation> | ||
<property> | ||
<name>!test</name> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be true even when using -Dtest (because multiple forks and you can specify multiple tests)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just copying from plugin-pom
. Skipped when -Dtest=SomeTest
is specified in case this is a developer run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I possibly should have cleaned that up when I was there.
problem is if you use -Dtest=SomeTest,OtherTest -DforkCOunt=2
your output is garbage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is hard to read. Still better IMO than showing nothing.
@@ -25,6 +28,8 @@ | |||
*/ | |||
@Test | |||
public void runSampleBenchmark() throws Exception { | |||
assumeFalse(Functions.isWindows()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
benchmarks don't work on windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dunno, had some problems here and it did not seem important.
well a quick look at PluginManager I found one bug (but not the one you are looking for...)
|
…ectoryNotEmptyException
mvn -pl test surefire:test -Dsurefire.skipAfterFailureCount=1 -Dtest=DisablePluginCommandTest fails even if I delete the bodies of all the test methods. Thus I think that it is |
I tried this, without success (no plugin JARs show up in the list of open file handles, despite the error referring to a handle on diff --git test/pom.xml test/pom.xml
index b955406376..bab03c95b0 100644
--- test/pom.xml
+++ test/pom.xml
@@ -227,6 +227,23 @@ THE SOFTWARE.
<artifactId>objenesis</artifactId>
<scope>test</scope>
</dependency>
+ <dependency>
+ <groupId>org.kohsuke</groupId>
+ <artifactId>file-leak-detector</artifactId>
+ <version>1.13</version>
+ <classifier>jar-with-dependencies</classifier>
+ <scope>test</scope>
+ <exclusions>
+ <exclusion>
+ <groupId>args4j</groupId>
+ <artifactId>args4j</artifactId>
+ </exclusion>
+ <exclusion>
+ <groupId>org.kohsuke</groupId>
+ <artifactId>asm6</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
</dependencies>
<build>
@@ -265,6 +282,12 @@ THE SOFTWARE.
</artifactItems>
</configuration>
</execution>
+ <execution>
+ <id>properties</id>
+ <goals>
+ <goal>properties</goal>
+ </goals>
+ </execution>
</executions>
</plugin>
<plugin>
@@ -272,7 +295,7 @@ THE SOFTWARE.
<artifactId>maven-surefire-plugin</artifactId>
<!-- version specified in grandparent pom -->
<configuration>
- <argLine>${jacocoSurefireArgs} -Dfile.encoding=UTF-8 -Xmx1g -Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
+ <argLine>${jacocoSurefireArgs} -Dfile.encoding=UTF-8 -Xmx1g -Djdk.net.URLClassPath.disableClassPathURLCheck=true -javaagent:${org.kohsuke:file-leak-detector:jar:jar-with-dependencies}</argLine>
<systemPropertyVariables>
<!-- use AntClassLoader that supports predictable file handle release -->
<hudson.ClassicPluginStrategy.useAntClassLoader>true</hudson.ClassicPluginStrategy.useAntClassLoader>
diff --git test/src/test/java/hudson/cli/DisablePluginCommandTest.java test/src/test/java/hudson/cli/DisablePluginCommandTest.java
index b7281ba71d..594fb8d926 100644
--- test/src/test/java/hudson/cli/DisablePluginCommandTest.java
+++ test/src/test/java/hudson/cli/DisablePluginCommandTest.java
@@ -42,15 +42,41 @@ import static hudson.cli.CLICommandInvoker.Matcher.failedWith;
import static hudson.cli.CLICommandInvoker.Matcher.succeeded;
import static hudson.cli.DisablePluginCommand.RETURN_CODE_NOT_DISABLED_DEPENDANTS;
import static hudson.cli.DisablePluginCommand.RETURN_CODE_NO_SUCH_PLUGIN;
+import java.io.File;
+import java.io.PrintWriter;
+import java.util.List;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.notNullValue;
+import org.junit.After;
import static org.junit.Assert.*;
import org.junit.Ignore;
+import org.kohsuke.file_leak_detector.Listener;
public class DisablePluginCommandTest {
@Rule
- public JenkinsRule j = new JenkinsRule();
+ public JenkinsRule j = new JenkinsRule() {
+ @Override
+ public void after() throws Exception {
+ try {
+ super.after();
+ } finally {
+ PrintWriter pw = new PrintWriter(System.err, true);
+ for (Listener.Record r : Listener.getCurrentOpenFiles()) {
+ if (r instanceof Listener.FileRecord) {
+ File f = ((Listener.FileRecord) r).file;
+ if (f.getAbsolutePath().matches(".*plugins.*[.]jar")) {
+ r.dump("", pw);
+ } else {
+ pw.println("(also " + f + ")");
+ }
+ } else {
+ pw.println("(also " + r + ")");
+ }
+ }
+ }
+ }
+ };
/**
* Can disable a plugin with an optional dependent plugin. |
I ran handle after a failure, while the JVM remained open, but it showed no processes holding a handle onto any files in the temporary |
|
Note that |
WRT Also, " 100% evil dir name " is not a valid directory name on Windows because it has trailing whitespace, that's why |
|
Yes, I figured this class of failure out with b0e05f5, so it should be straightforward to fix the others.
OK, can just be skipped or modified on Windows I suppose.
Sounds right. To be clear, this miscellaneous ones I can probably fix quickly enough, though of course a PR to |
I'll dig into a problem with |
FYI, the docker image for jdk11 has been updated and should now work for ACI. I have not had a chance to test it yet, but the JDK was updated to 11.0.6 which should have the fixes. |
What makes you say that? it i perfectly valid (you can not create it in explorer as it tries to be helpful however...) |
If you look at build log of
|
JDK bug. https://bugs.openjdk.java.net/browse/JDK-8190546 the name is actually valid on windows, so its just that the JDK is brain dead here. |
Okay, but they do not want to fix it. So the path of least resistance is just to accept it and use a different directory name. Especially given the fact that test doesn't really care about that whitespace. |
I have not found the time to get back to this, and no one else seems to have either, so closing this for now so we do not waste build resources on something known to be broken. Great task for volunteers to pick up! |
See #4178 (comment) for context.