Create version.md with helm chart and docker image version overview

[pvannierop]

Change

This PR will add a new script (version_scan) to the codebase. This script creates a Bill of Materials (helm chart and docker image versions) of the deployment represented by the RADAR-Kubernetes defaults, and writes a versions.md file in the root of the project. The versions.md file is created from a GitHub Action that is triggered on any push to the main branch.

Benefits

The automatically generated versions.md file provides a convenient way to inspect/reference the installed versions of helm charts and docker images. It facilitates analysis of deployment by deployers as well as provide a component list that should be subjected to vulnerability scanning efforts.

Example of versions.md

This file is automatically generated (by the version_scan script). Do not edit manually.

Helm Charts

Chart	Version
app-config	0.2.4
app-config-frontend	0.2.3
...

Containers

Image	Helm Charts
andrewgaul/s3proxy:travis-1430	s3-proxy-0.1.3
bats/bats:v1.1.0	grafana-6.26.8
...

Init Containers

Image	Helm Charts
docker.io/bitnami/minio:2023.7.11-debian-11-r0	minio-12.6.9
docker.io/bitnami/kubectl:1.29	velero-2.30.1
...

[keyvaann]

Also lets push this first into dev and then it will be released with the rest of the changes

[pvannierop]

@keyvaann

I have updated the target branch to dev.

We discusses at the The Hyve developers meeting that a pre-commit hook maybe a better alternative since this does not create a separate commit after each merge. However, I think in this case a precommit hook would not be very nice since the task is rather long running. What is you opinion?

[keyvaann]

@keyvaann

I have updated the target branch to dev.

We discusses at the The Hyve developers meeting that a pre-commit hook maybe a better alternative since this does not create a separate commit after each merge. However, I think in this case a precommit hook would not be very nice since the task is rather long running. What is you opinion?

Precommit hooks would also be nice but we need a job in the CI to check if the precommit hook has actually ran, the similar way that we block PRs in radar-helm-charts if the documentation hasn't been updated.
But also since your change will only apply to the main branch and we don't push to it that often I think commit history won't be too polluted with they way you've implemented it right now.

[Bdegraaf1234]

This is great! Very useful for deployment repositories too.

Appversions may be nice at some point, as the image link can be something like latest/dev. However, I think the only way to achieve that is to actually pull it from the source so it seems like a bit too much work.