Github workflow to build container images

[ressu]

While it's a good idea to build containers manually, it adds additional overhead to anyone who is maintaining the exporter in a container environment. GitHub has actions and Container Registry, so maintaining a prebuilt container is no longer an overhead.

This workflow builds the container and uploads to GHCR when ever a new release is made and when a push to main or dev happens. Latter ones are useful for development flows, while the release flows will push a latest tag in addition to the release tag versions, which allows easy access to old versions as well as current versions.

[mbugert]

Thanks, I appreciate the suggested changes.
I agree that the current docker image strategy could be made more convenient. The ugliness mainly comes from the yaml config file which could be replaced entirely by envvars. Once that is done, self-contained docker images could be built and shipped to users. Until then, I would want to keep this PR open.

Unfortunately, it can take quite a while (weeks/months, tbd) until I have the time to make these changes (several work-related commitments), so I hope you don't hate me for not merging it in right away. 😜

[ressu]

Based on the discussion in #15 (comment). Would you be open to changing the configuration to use targets from scrape config? That could allow removing the configuration completely and providing all information runtime

[mbugert]

Yep, I would prefer reading targets from the prometheus config! 😄 But I expect it to be quite a significant implementation effort.

[ressu]

Cool, let me see what I can do.. I'm mostly scratching my own itch, so I might be able to refactor things appropriately. Lets keep the other PR on hold until then too.