-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] GHCR registry should use 3.2
images with LEAP, not Alpine base
#2422
Comments
3.2
images with Alpine base3.2
images with LEAP, not Alpine base
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. |
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:
The above would drop the |
Related:
Expected behavior
GHCR and DockerHub registries should be publishing the same image builds.
Actual behavior
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
testssl.sh/.github/workflows/docker-3.2.yml
Lines 61 to 63 in b21c5ee
testssl.sh/Dockerfile.git
Line 3 in b21c5ee
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 usingCOPY
:testssl.sh/Dockerfile.git
Line 14 in b21c5ee
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
The CI itself is only using the build version:
testssl.sh/.github/workflows/docker-3.2.yml
Line 57 in b21c5ee
There is rarely a need for this style of image building?
testssl.sh
is going to also have theDockerfile
associated to it.Dockerfile
in sync with that commit?git clone
and building from theDockerfile
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
EDIT: You've been reluctant to remove it because of the possibility of someone else building from it. There is
no other knownconsumer 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
and3.2
these branch triggers, both with scheduledcron
jobs:testssl.sh/.github/workflows/docker-3.2.yml
Lines 3 to 9 in b21c5ee
testssl.sh/.github/workflows/docker-3.0.yml
Lines 3 to 9 in ece9447
However scheduled workflows are only from the default branch (now
3.2
): https://github.com/drwetter/testssl.sh/actions/workflows/docker-3.2.ymlAs 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.ymlYou 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.
The text was updated successfully, but these errors were encountered: