feat: add a helm chart with the releaser action

[allanger]

Hi!

I thought of starting to use sql_exporter on k8s, but I found out that there was no helm chart available, so I've decided to come up with one.

This PR contains the helm chart and the new GitHub action that will lint, test and release that chart. The release action requires GitHub pages enabled, because it's using it as a helm repository, you can check it in my fork: https://github.com/allanger/sql_exporter/tree/gh-pages

In this PR, release is enabled only when the action is triggered by pushing to the master, but since the action is checking if there were changes to the chart before releasing, it will require one more commit with a version bump to release the first version.

When the new chart version is released, it will be put to GitHub releases and GitHub pages branch will be updated. Having it in GitHub releases may not be a desired behavior, since it will conflict with actual release. If it's the case, I guess it's possible to disable it and put releases directly to the pages branch.

What about maintenance?

I can take care of it for a time being. But basically, if there are no breaking changed introduced to the tool, the whole maintenance will be just upgrading helm/Chart.yaml:appVersion to the new app version and helm/Chart.yaml/version to the following one.

[burningalchemist]

Hey @allanger, thanks for your contribution! No objections here. The reason there's no helm chart is mostly people use sql_exporter as a container and put into their integrations. However, if there's a case to deploy it as a separate helm chart, then let it be. 👍

[tonobo]

Howdy everyone, it's possibly a bit out of context, but i'm interested in having a kubernetes controller. At least for handling the queries / metrics. Quite similar how prometheus rules work in the end. Is this a bit over the top for the project itself or would you like to see a contribution in there.

[burningalchemist]

Hey @tonobo, would you mind creating a separate discussion in Discussions? I would be curious to learn more about the idea, etc. 👍 It's just out of topic for this particular PR, still quite interesting. 🙂

[burningalchemist]

@allanger Thanks again for your contribution! I guess we're good to go. 👍🚀

[allanger]

If this PR is scheduled for a release with the new version, once the new version is released and the chart is merged, we could update fields version and appVersion in the chart.yaml then the chart should be released as well and become available from gh-pages branch.

[burningalchemist]

I've just noticed that the workflow is set to run on every push event. We might need to update the condition there to tags and/or workflow_dispatch:

on:
  workflow_dispatch:
  push:
    tags:
    - '*.*.*'

Could you please make this change?

[allanger]

It's triggered on every push because of the design. Chart doesn't have the same workflow as the app. Tools that are used for linting, testing, and releasing are detecting changes comparing to the master branch. So if a change to the chart is required, you don't need to push tags, but make a commit with an updated chart version to the master

[burningalchemist]

Ok, sounds good to me. 👍