You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could also consider removing the need for the build arg in CI by preferring the dist-local stage. This would be implicit if we swap the dist-git + dist-local stage order of appearance in the Dockerfile to match the openSUSE Dockerfile since the last stage is the default one to build.
dist-git is effectively redundant and could be dropped in favor of the alternative shown in the Dockerfile.md docs (which makes no mention of these two final stages, as there isn't a need to raise awareness).
That said the UX may not be as pleasant, so you could keep the dist-git stage for a niche use-case if you think it's worthwhile? 🤷♂️
Proposed (if keeping dist-git, but as an opt-in target instead) with a local Dockerfile copy, but remote source:
# NOTE: Only cloning for the `Dockerfile`
git clone --branch 3.2 --depth 1 https://github.com/testssl/testssl.sh .# Optional - Set the `GIT_URL` build arg too if preferring a fork instead of upstream repo:
docker build \
--tag localhost/testssl.sh:3.2-alpine \
--target dist-git \
--build-arg GIT_BRANCH=3.2 \
.
The main benefit of the latter with a dist-git target is that the user doesn't have to think about the two different URL inputs (shouldn't be much of a concern, they'd likely copy/paste from docs and it's either a one off or automated script, assuming you actually have any users that care about this support in the first place).
Either way, you could have automated CI builds at a single branch that changes GIT_BRANCH to official releases or some PR branch/fork, that's the main benefit, but as documented this would work fine with dist-local with a remote context URL to a repo + branch.
If they really care about size they should prefer dist-local with manual git clone so that .dockerignore can be used to shave off another 8MB.
The text was updated successfully, but these errors were encountered:
Taken from #2768
NOTE:
We could also consider removing the need for the build arg in CI by preferring the
dist-local
stage. This would be implicit if we swap thedist-git
+dist-local
stage order of appearance in theDockerfile
to match the openSUSEDockerfile
since the last stage is the default one to build.dist-git
is effectively redundant and could be dropped in favor of the alternative shown in theDockerfile.md
docs (which makes no mention of these two final stages, as there isn't a need to raise awareness).That said the UX may not be as pleasant, so you could keep the
dist-git
stage for a niche use-case if you think it's worthwhile? 🤷♂️Proposed (without
dist-git
):docker build --tag localhost/testssl.sh:3.2 https://github.com/testssl/testssl.sh.git#3.2 # Alpine variant requires `--file`: docker build \ --tag localhost/testssl.sh:3.2-alpine \ --file https://raw.githubusercontent.com/testssl/testssl.sh/3.2/Dockerfile-alpine \ https://github.com/testssl/testssl.sh.git#3.2
Proposed (if keeping
dist-git
, but as an opt-in target instead) with a localDockerfile
copy, but remote source:The main benefit of the latter with a
dist-git
target is that the user doesn't have to think about the two different URL inputs (shouldn't be much of a concern, they'd likely copy/paste from docs and it's either a one off or automated script, assuming you actually have any users that care about this support in the first place).Either way, you could have automated CI builds at a single branch that changes
GIT_BRANCH
to official releases or some PR branch/fork, that's the main benefit, but as documented this would work fine withdist-local
with a remote context URL to a repo + branch.If they really care about size they should prefer
dist-local
with manualgit clone
so that.dockerignore
can be used to shave off another 8MB.The text was updated successfully, but these errors were encountered: