[FEATURE] GHCR registry should use `3.2` images with LEAP, not Alpine base about testssl.sh

[drwetter]

IIRC I asked you when you refactored the Dockerfile whether you could do the same for the GCHR Dockerfile and your responded that you lacked time.

Don't know who's actually using the GCHR file and I can't recall atm the circumstances why it is like it is. Maybe @jauderho was involved.

If you believe it should be changed, you're welcome to make a proposal. It would be great to keep it short and concise.

[polarathene]

It would be great to keep it short and concise.

I am open to contributing a PR to revise your Github Actions with the docker image workflows. It may not be "short and concise", but well intentioned and beneficial for maintenance. The technical reasoning is below.

I propose:

• A separate scheduled workflow file in your default branch (currently 3.2) which is required for this to actually work for scheduled builds of 3.0 (or any other branch that isn't the default). This workflow would have separate jobs defined to build the different versions (release branches) you want to support (similar to this example, although it's jobs are for a different purpose).
• As noted by the example reference, the jobs will reference a reusable workflow.
  • Those likewise use the default branch, but should explicitly reference it with @ to work the way you'd expect.
  • You could have each job reference the specific branch instead, and maintain variants of the reusable workflow called, but I don't think you'd need this and it'd be better to keep it consistent to the same reference branch (you could keep that in sync with your default branch, or have a separate dedicated branch for this). The only real change needed is to provide an input (the release branch), this will be easier to maintain and reason about.
• The reusable workflow will handle the build + publish process. It will be similar to what you have already, but I'd like to revise it a little for your benefit.
  • Unfortunately your tags don't use proper semver, and your current process is to override the 3.0 / 3.2 tag without support for specific releases (which could be supported).
  • Instead, the tags will match your current workflow by using the branch name as the tag.
  • I can additionally include a default :latest tag that points to your current default branch (3.2 presently, but you tend to adjust this as the version changes rather than an edge or similar unreleased branch (typically main/master or develop)). It will adapt to your default branch changes implicitly, meeting the expectations of your users when no tag is specified?
• I would suggest having both GHCR and DockerHub published this way for consistency. Disabling your existing DockerHub integration in favour of this workflow, centralizes your management of it. This has been discussed in the past, but you seemed a bit reluctant towards it.
• While I can provide you with a single reusable workflow, I am fond of splitting the responsibility of build and publishing to separate workflow files.
  • For example, should you decide to run tests via the container in CI, you can easily reuse the build workflow this way without any publishing concerns involved until tests pass.
  • The reusable workflow will already be leveraged between your branches being updated and the scheduled jobs, where both scenarios are building and publishing the image (at least for GHCR, your DockerHub builds won't benefit unless you're willing to publish from Github Actions).

The above would drop the Dockerfile.git as I don't think it serves any real value for you to have and maintain. Users should just clone the repo + branch of interest and build the Dockerfile.