testssl/testssl.sh

Preferring the `dist-local` stage ?

Closed this issue · 0 comments

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