Many failing tests on Windows machines

[Belair34]

Environment:

• Jib version: jib-cli v0.11.0
• Build tool: Gradle wrapper included
• OS: Windows 10

Description of the issue:
Multiple failing integration tests seemingly due to running the tests on windows instead of Linux (ex: expecting "\n" but getting "\r\n") among some other types of failures. Using intelliJ Community IDE.

Expected behavior:
Integration tests all pass given no changes have been made since cloning the project.

Steps to reproduce:

1. Clone main branch on Windows 10 machine
2. Set up Java (using Temurin 11.0.16)
3. Open project in IntelliJ and ensure java version is correct
4. Set system environment variable JIB_INTEGRATION_TESTING_LOCATION to localhost:9990
5. run './gradlew clean goJF build integrationTest' in IntelliJ's gradle section

Additional Information:
We have been working on solving this issue by using system.lineSeparator() in more places, amending some docker commands, and even messing with our groovy version. Another notable thing is that cloning the repo in WSL can cause discrepancies between System.lineSeparator() and the line separators used in text files when running the tests in Windows.

[zhumin8]

Thanks for reporting. I wonder if this could be an IDE issue? For example, for "\n" vs "\r\n", you can configure in Intellij for which style you want (Intellij configure line separators).
Alternatively, you could try to test without IDE. Please followup is you still see issues this way.

Update:
In fact, there has been some known compatibility issues with Jib and windows, see more in #99 and #2288. Building windows image with Jib may not be a good idea (discussion).

[Belair34]

Thanks for the quick response! That seems like a good solution for the last thing I mentioned regarding WSL, however it doesn't seem to solve most of the "\n" vs "\r\n" issues because I believe the"\r\n" comes from something that is generated during the tests. For example, the StringWriter in this test ends up with "\r\n" at the end even though it is expecting "\n"

jib/jib-cli/src/integration-test/java/com/google/cloud/tools/jib/cli/JarCommandTest.java

Lines 69 to 84 in aca26b3

	@Test
	public void testErrorLogging_directoryGiven() {
	StringWriter stringWriter = new StringWriter();
	CommandLine jibCli = new CommandLine(new JibCli()).setErr(new PrintWriter(stringWriter));
	Path jarFile = Paths.get("/");
	Integer exitCode =
	jibCli.execute("jar", "--target", "docker://jib-cli-image", jarFile.toString());
	assertThat(exitCode).isEqualTo(1);
	assertThat(stringWriter.toString())
	.isEqualTo(
	"[ERROR] The file path provided is for a directory. Please provide a path to a JAR: "
	+ jarFile.toString()
	+ "\n");
	}

There is also another error: Cannot run program "./gradlew" (in directory "C:\Users\User\AppData\Local\Temp\junit2372789025395354886\junit15493631909377854876"): CreateProcess error=2, The system cannot find the file specified when running tests like the following:

jib/jib-cli/src/integration-test/java/com/google/cloud/tools/jib/cli/WarCommandTest.java

Lines 81 to 105 in aca26b3

	@Test
	public void testWar_jetty() throws IOException, InterruptedException {
	servletProject.build("clean", "war");
	Path warParentPath = servletProject.getProjectRoot().resolve("build").resolve("libs");
	Path warPath = warParentPath.resolve("standard-war.war");
	Integer exitCode =
	new CommandLine(new JibCli())
	.execute("war", "--target", "docker://exploded-war", warPath.toString());
	assertThat(exitCode).isEqualTo(0);
	String output =
	new Command(
	"docker",
	"run",
	"--rm",
	"--detach",
	"-p8080:8080",
	"exploded-war",
	"--privileged",
	"--network=host")
	.run();
	containerName = output.trim();
	assertThat(getContent(new URL("http://" + dockerHost + ":8080/hello")))
	.isEqualTo("Hello world");
	}

Note that we don't necessarily want to build windows images with Jib, rather we want to develop and test Jib on windows machines. If it is determined to have any value, we may make a PR/draft of some changes we're coming up with to make this work.

[elefeint]

@Belair34 We don't support a development flow on Windows because nobody on the team uses Windows.
In general, development flows on Linux or MacOS (basically also *nix nowadays) are more common and better tested in open source projects.