Fix jkube-kit/build/service module's unit tests on Windows

[rohanKanojia]

Component

JKube Kit

Task description

Description

Related to #1338

⚠️ A windows machine is required to reproduce and fix problems in this issue.

Originally posted by @l3002 in #2629 (comment)

a few tests are still failing in jkube-kit/build/service module. Here's a screenshot for your reference

When running mvn clean install on Windows, I see the following tests failing in jkube-kit/build/service module:

• WatchServiceTest

TODO: Figure out what's not working as expected and propose a way to fix this

[l3002]

@rohanKanojia, I can pick this up, Please assign this to me.

[rohanKanojia]

I haven't checked what's causing the failure. Make sure you share your findings for root cause first before fixing the issue.

[l3002]

Yeah @rohanKanojia, I'm just trying to figure that out only, I'll first rule out any possible issues with my local environment. I am still not sure if this is a issue with my local machine or the module itself.

[l3002]

@rohanKanojia, I have been a bit busy over the past few days, I hope it won't be a problem if this takes a few more day?

[rohanKanojia]

@l3002 : No problem, take your time.

[l3002]

@rohanKanojia, Seems like the problem is occurring due to the outputDirectory used in WatchContext.buildContext. See below:

Here, we are using the absolute path of the directory rather than using just the name. Due to which when we invoke BuildDirs.getDir(), it uses that absolute path of the output directory rather than just using the name of the output directory.

This method then returns a file path like this:

C:\Users\Tdgf\AppData\Local\Temp\junit8869024635707207334\C:\Users\Tdgf\AppData\Local\Temp\junit8869024635707207334\target\test-app\build

and is used in the BuildDirs.createDir() leading to the throw statement

We can solve the issue by changing the absolute path to just the name. See below:

Changing the getAbsolutePath() to getName().

[l3002]

I've tried building the project on both windows and linux after the changes and it seems to pass all the test in jkube-kit/build/service module. If you are ok with it then I can raise a pull request for the same.

[rohanKanojia]

@l3002 : Nice work! Your analysis looks correct to me. outputDirectory is a relative path to base directory not absolute path.

It was working incorrectly on Linux as well, but we didn't notice it because on Linux it was creating nested directories:

/tmp/junit15664568372380832823
├── file.txt
├── target
└── tmp
    └── junit15664568372380832823
        └── target
            └── test-app
                ├── build
                └── work

[l3002]

@rohanKanojia: Thanks, Should I raise a PR with the mentioned changes?

Also, After making those changes to the fork on my local system and building the project, there is still a unit test failing in enricher module. Could you please create an issue for that too?

While building the project in windows, the following test seems to be failing in jkube-kit/enricher/api module:

• MetadataVisitorTest

[rohanKanojia]

You can go ahead and create pull request 👍

[rohanKanojia]

Also, After making those changes to the fork on my local system and building the project, there is still a unit test failing in enricher module. Could you please create an issue for that too?

While building the project in windows, the following test seems to be failing in jkube-kit/enricher/api module:

• MetadataVisitorTest

Please don't hesitate in opening up new issue on repository. Anyone can create issues. Just try to follow the same format I used in previous issues.

[l3002]

Got it.

[manusa]

This method then returns a file path like this:

C:\Users\Tdgf\AppData\Local\Temp\junit8869024635707207334\C:\Users\Tdgf\AppData\Local\Temp\junit8869024635707207334\target\test-app\build

It was working incorrectly on Linux as well, but we didn't notice it because on Linux it was creating nested directories:

I haven't checked, but this looks like a bug. Probably we should warn about this or even throw an exception if this configuration is provided.

[rohanKanojia]

This outputDirectory field is set from plugins

https://github.com/eclipse/jkube/blob/5e5b596a026c772cfee561b8a74880bf816b3f44/kubernetes-maven-plugin/plugin/src/main/java/org/eclipse/jkube/maven/plugin/mojo/build/AbstractDockerMojo.java#L437

https://github.com/eclipse/jkube/blob/5e5b596a026c772cfee561b8a74880bf816b3f44/gradle-plugin/kubernetes/src/main/java/org/eclipse/jkube/gradle/plugin/task/AbstractJKubeTask.java#L140

It's default value is set to outputDir/docker if not set:

https://github.com/eclipse/jkube/blob/5e5b596a026c772cfee561b8a74880bf816b3f44/kubernetes-maven-plugin/plugin/src/main/java/org/eclipse/jkube/maven/plugin/mojo/build/AbstractDockerMojo.java#L171-L172

https://github.com/eclipse/jkube/blob/5e5b596a026c772cfee561b8a74880bf816b3f44/gradle-plugin/kubernetes/src/main/java/org/eclipse/jkube/gradle/plugin/KubernetesExtension.java#L608

[manusa]

Yes, I know.
This is exactly my point. Maybe we want to warn those users who provide an absolute path in the outputDirectory configuration, since JKube won't behave as they expect to.

[l3002]

@manusa, I had a concern regarding this too, if this was undetected here then anyone configuring it manually might face issue later on. We should provide exception if anyone tries to use the absolute path instead to the relative path.