[FEATURE] GHCR registry should use 3.2 images with LEAP, not Alpine base

[polarathene]

Related:

• Refactor Dockerfile.git to use opensuse leap  #2348
• Docker image for ARM64 #2085 (comment)

Expected behavior

GHCR and DockerHub registries should be publishing the same image builds.

Actual behavior

# Different images:
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive docker.io/drwetter/testssl.sh:3.2
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive ghcr.io/drwetter/testssl.sh:3.2

Your DockerHub and GHCR publishing seems to be handled differently? You have a Github Actions workflow for the GHCR registry, but it's targeting the Dockerfile.git (Old Alpine) image in the 3.2 branch:

testssl.sh/.github/workflows/docker-3.2.yml

Line 55 in b21c5ee

file: Dockerfile.git

testssl.sh/.github/workflows/docker-3.2.yml

Lines 61 to 63 in b21c5ee

	tags: |
	ghcr.io/${{ github.repository }}:${{ env.BUILD_VERSION }}
	ghcr.io/${{ github.repository }}:latest

testssl.sh/Dockerfile.git

Line 3 in b21c5ee

FROM alpine:3.17

DockerHub is apparently watching the repo and builds automatically (thus the Dockerfile used from each branch associated to a tag?): #2085 (comment)

---

This file was only added AFAIK for CI usage, where it builds differently by performing a git clone of the repo instead of using COPY:

testssl.sh/Dockerfile.git

Line 14 in b21c5ee

&& git clone --depth 1 --branch ${BUILD_VERSION} $URL /home/testssl \

Allowing via build ARG to control the repo and branch (ARCHIVE_URL doesn't appear to be used):

testssl.sh/Dockerfile.git

Lines 7 to 9 in b21c5ee

	ARG BUILD_VERSION
	ARG ARCHIVE_URL=https://github.com/drwetter/testssl.sh/archive/
	ARG URL=https://github.com/drwetter/testssl.sh.git

The CI itself is only using the build version:

testssl.sh/.github/workflows/docker-3.2.yml

Line 57 in b21c5ee

build-args: BUILD_VERSION

---

There is rarely a need for this style of image building?

• Usually any fork of testssl.sh is going to also have the Dockerfile associated to it.
• This would just be building with the source a remote of a repo + branch where you don't want to use the Dockerfile in sync with that commit?
• What advantage / need does it serve over a local git clone and building from the Dockerfile in that repo?

IIRC, it was possibly used in the past to have the CI support building the different branches of this project. However the CI should be triggered and building with the correct branch source here?:

testssl.sh/.github/workflows/docker-3.2.yml

Lines 21 to 22 in b21c5ee

	- name: Source checkout
	uses: actions/checkout@v4

EDIT: You've been reluctant to remove it because of the possibility of someone else building from it. There is no other known consumer beyond the CI, I'd encourage dropping it until you have a valid reason to keep it (revert the removal and address the image changes required at that point).

I am aware of one user @jauderho that would need to update their workflow, should the file be dropped. Perhaps they can weigh in on if that'd be an issue for them.

---

Likewise you have for both 3.0 and 3.2 these branch triggers, both with scheduled cron jobs:

testssl.sh/.github/workflows/docker-3.2.yml

Lines 3 to 9 in b21c5ee

	on:
	push:
	branches:
	- 3.2
	workflow_dispatch:
	schedule:
	- cron: "0 8 * * 1"

testssl.sh/.github/workflows/docker-3.0.yml

Lines 3 to 9 in ece9447

	on:
	push:
	branches:
	- 3.0
	workflow_dispatch:
	schedule:
	- cron: "0 8 * * 1"

However scheduled workflows are only from the default branch (now 3.2): https://github.com/drwetter/testssl.sh/actions/workflows/docker-3.2.yml

As you'll see no scheduled builds are in the 3.0 history for the past year: https://github.com/drwetter/testssl.sh/actions/workflows/docker-3.0.yml

You could adapt the scheduled workflow of docker-mailserver, which references a workflow to run and the associated branch (@).

That lives on the default branch, and without providing a branch reference, will run the referenced workflow from that scheduled run workflows last commit (not what you want when referencing workflows to run that get updated), thus referencing the branch is important.

[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.