PM-1506 Helm Docs workflow

[Smorci]

This PR introduces the helm docs job.

The template has been moved here so subsequently every job that checks out the repository has the template.

The job gets the changed directories and then checks if those directories have the Chart.yaml file. If the file exists it executes the helm-docs workflow from the workflows repository.

I might have to merge it even if it is faulty to test it. Does anybody know another way to test this?

[simisimis]

Approving this so you could continue working on this, however I will want to get back to it, as I think this should be packaged as a local job packaged with that template you're using. And not put that template in a .github dir

[Smorci]

I personally don't think .github is a bad place for a README template that defines how READMEs in the repository look.

I tried looking for solutions to package and use this together wtih the workflow, but I haven't found the desired solution.

I will not merge this, and get everyones opinion, and I will test tomorrow.

[johnmarcou]

I personally don't think .github is a bad place for a README template that defines how READMEs in the repository look.

I tried looking for solutions to package and use this together wtih the workflow, but I haven't found the desired solution.

I will not merge this, and get everyones opinion, and I will test tomorrow.

I would keep the .github folder for Github related files. If, hypothetically, we would move to another git repo hosting platform, we shouldn't have to reconfigure helm-docs paths.

I suggest to have the global template file at the root of the repository to be applied to all charts, at least for now.
We could use the README.md.gotmpl default name, but I personally have a slight preference for .README.md.gotmpl.

Also, I have noticed that the helm-docs binary --template-files help message is a bit misleading.
It can be then executed from the root of the repo with: helm-docs -t ./README.md.gotmpl or helm-docs -t ./.README.md.gotmpl.

Also, do we really need a custom template at that stage? Would the default template (from the binary) be enough? What would it be missing?

[johnmarcou]

question: I think the workflow is this PR is not relevant anymore. Should we mark this PR back to draft @Smorci?

[Smorci]

@johnmarcou I am closing this because as discussed we are going to approach the problem from the pre-commit angle.