[FEATURE_REQUEST] Expose a public API

[dramich]

Description of the problem/feature request
Currently all code is hidden behind the internal dir, which means none of the code can be imported and used anywhere else.

Expose a public API so the packages can be consumed elsewhere (or just change the dir name to pkg 😄 ) which would allow for the linter to be used internally in other places as opposed to having to fork out to a process to run the linter.

[viswajithiii]

Hi @dramich, thanks for filing this, and apologies for the late response! We've been wondering when somebody would ask about this. 🙂

We had intentionally left all the code inside internal to give us some room to make breaking changes, but recognize this is inconvenient. We'd still like to be cautious with how much we expose in our public API surface.

It would be helpful to understand how you would use it if, hypothetically, we just renamed internal to pkg today. This would help me to move enough code to pkg that you, and other users, can use KubeLinter as a library while leaving things we want to retain as implementation details inside internal.

Let us know, and we can make the changes soon!

[dramich]

Hey @viswajithiii, I am glad you saw this coming. 😄

At Rancher, we build a lot of charts, this can be both charts we create and maintain and also pulling in upstream charts and modifying them for our use case. As part of this we need to ensure the charts that we are publishing are valid and also can meet our requirements (they work, run in hardened clusters etc.). This is where I see kube-linter coming in to play for us as part of our charts build pipeline.

Looking through source I think if the run.Run command and things associated with it (the types in the sig) were exposed we would have everything we need. Which, I suppose, is most things. In theory we could build our context, which would just be all the files from the chart in memory, init the checks we want and run.

[viswajithiii]

Hey @viswajithiii, I am glad you saw this coming. 😄

At Rancher, we build a lot of charts, this can be both charts we create and maintain and also pulling in upstream charts and modifying them for our use case. As part of this we need to ensure the charts that we are publishing are valid and also can meet our requirements (they work, run in hardened clusters etc.). This is where I see kube-linter coming in to play for us as part of our charts build pipeline.

Looking through source I think if the run.Run command and things associated with it (the types in the sig) were exposed we would have everything we need. Which, I suppose, is most things. In theory we could build our context, which would just be all the files from the chart in memory, init the checks we want and run.

Understood, thanks! I'll be sending out a PR later today or tomorrow.

[viswajithiii]

Hi @dramich, starting in v0.1.6, which we just released, you should be able to use it as a library. Let me know if you run into any trouble, and thanks again for filing this issue!