GitUtil : Remove redundant null check for `gitFolder` in `getGitRepository` method

[rohanKanojia]

Component

JKube Kit

Task description

Description

We have this null check for currentDir in GitUtil :

https://github.com/eclipse/jkube/blob/fddd604457c98a197bd8b2f3cbb3167dde2a9b3d/jkube-kit/common/src/main/java/org/eclipse/jkube/kit/common/util/GitUtil.java#L36-L39

It is used in two places both of which come from project.getBaseDirectory(), we always set this field in Maven and Gradle plugins.

I think we can remove this null check.

Expected Behavior

Remove this null check from GitUtil

Acceptance Criteria

• [ ] null check is removed from GitUtil
• [ ] passes after making this change
• [ ] GitAnnotationsIT should pass after making this change

How to manually test my changes

Kubernetes

If you don't have a real Kubernetes cluster available (most probably), you can use Minikube or Kind to test with a local cluster.

• Minikube get started guide
• Kind (Requires Docker) quick start

OpenShift

If you don't have a real OpenShift cluster available (most probably), you can use Red Hat's developer Sandbox for Red Hat OpenShift. The only requirement is to have a Red Hat account.

Once you have your Sandbox environment, you'll need to download the oc tool from the cluster console. (Press the ? icon and from the context menu select Command line tools, you'll be redirected to https://$subdomain.openshiftapps.com/command-lines-tools where you'll be able to download the CLI for your platform)

[ajayl83]

@rohanKanojia can i pick this up?

[ajayl83]

@rohanKanojia this null check is needed , consider when you dont have currDir then you create it as new File(System.getProperty("basedir", ".")) by default then here this parameter is not at all needed, and if in case its null and we dont create default we will end up with NPE on line 53 while we try to find gitfolder without checking null in first place.

so its always good to do defensive programming and its better to validate all preconditions here, let me know what do you think about it?

[rohanKanojia]

its always good to do defensive programming and its better to validate all preconditions here

You're right about this. This might be an issue if this utility class is used by users using jkube-kit as a direct dependency. However, at the moment I'm not sure there are users are using jkube-kit as a direct dependency. In our codebase we use it only in two places, JavaProject's base directory seems to be set always from maven and gradle plugin apis.

[manusa]

However, at the moment I'm not sure there are users are using jkube-kit as a direct dependency.

Then we might want to throw an exception instead. Objects.requireNonNull or something like that.

[ajayl83]

@manusa yes that would be the ideal way. ok will raise an PR

[rohanKanojia]

@ajayl83 : polite ping, are you still working on this? If not, could you please unassign?

[clarenced]

Hi @rohanKanojia I can help with this issue. :p

[rohanKanojia]

@clarenced : Thanks, please see Marc's comment https://github.com/eclipse/jkube/issues/2711#issuecomment-1963377448 for idea of what needs to be done.

[clarenced]

After some investigation, the method GitUtil.getGitRepository is called in 2 places :

from GItEnricher (L 54)

try (Repository repository = GitUtil.getGitRepository(getContext().getProjectDirectory())) {
 ...
}

and also from BaseGenerator (L272)

Repository repository = GitUtil.getGitRepository(project.getBaseDirectory());

Is there any situation where project.getBaseDirectory() or getContext().getProjectDirectory() can return null ? If it's not the case, we can safely remove the null-check.