Dockerfile templates for one-off images

[dsimansk]

@creydr @pierDipi @mgencur

Per my PR to onboard client repo to CI generators. I'd added very handy Dockerfile generators. There's similar issue to func-until image though. There's cli-artifact image produced to carry archives platform dependent binaries. It's utilized in OpenShift Console download view.

I still need to figure out how to template this. I don't want to every grow embeded templates. I was thinking about Dockerfile.template being stored in client midstream. And generator would discover it automagically or in a more controlled way through --from-template-file (whatever name makes sense) here.
But inherently every major change in templates like included metadata and so on would require change of the local file.

Would it be just simpler to have another template type stored as embedded template here?

For far I have only hardcoded everything version: https://github.com/openshift-knative/client/blob/release-v1.15/openshift/ci-operator/knative-images/cli-artifacts/Dockerfile

[dsimansk]

Template would look similar but with a custom build cmd and the COPY part .

# DO NOT EDIT! Generated Dockerfile for {{.main}}.
ARG GO_BUILDER={{.builder}}
ARG GO_RUNTIME=registry.access.redhat.com/ubi8/ubi-minimal

FROM $GO_BUILDER as builder

WORKDIR /go/src/github.com/knative/client
COPY . .

FROM $GO_RUNTIME


ENV CGO_ENABLED=1
ENV GOEXPERIMENT=strictfipsruntime
# Pass to cross compile target
ENV GOFLAGS="-tags=strictfipsruntime"

RUN make build-cross &&  \
    bash package_cliartifacts.sh

ARG VERSION={{.version}}
FROM $GO_RUNTIME

RUN mkdir -p /usr/share/kn/{linux_amd64,linux_arm64,linux_ppc64le,linux_s390x,macos_amd64,macos_arm64,windows}

COPY --from=builder /go/src/github.com/knative/client/kn-linux-amd64.tar.gz /usr/share/kn/linux_amd64/
COPY --from=builder /go/src/github.com/knative/client/kn-linux-arm64.tar.gz /usr/share/kn/linux_arm64/
COPY --from=builder /go/src/github.com/knative/client/kn-linux-ppc64le.tar.gz /usr/share/kn/linux_ppc64le/
COPY --from=builder /go/src/github.com/knative/client/kn-linux-s390x.tar.gz /usr/share/kn/linux_s390x/
COPY --from=builder /go/src/github.com/knative/client/kn-macos-amd64.tar.gz /usr/share/kn/macos_amd64/
COPY --from=builder /go/src/github.com/knative/client/kn-macos-arm64.tar.gz /usr/share/kn/macos_arm64/
COPY --from=builder /go/src/github.com/knative/client/kn-windows-amd64.zip  /usr/share/kn/windows/
COPY --from=builder /go/src/github.com/knative/client/LICENSE  /usr/share/kn/LICENSE
USER 65532

LABEL \
      com.redhat.component="openshift-serverless-1-{{.project_dashcase}}{{.component_dashcase}}-rhel8-container" \
      name="openshift-serverless-1/{{.project_dashcase}}{{.component_dashcase}}-rhel8" \
      version=$VERSION \
      summary="Red Hat OpenShift Serverless 1 {{.project}}{{.component}}" \
      maintainer="serverless-support@redhat.com" \
      description="Red Hat OpenShift Serverless 1 {{.project}}{{.component}}" \
      io.k8s.display-name="Red Hat OpenShift Serverless 1 {{.project}}{{.component}}"

[creydr]

I still need to figure out how to template this. I don't want to every grow embeded templates. I was thinking about Dockerfile.template being stored in client midstream. And generator would discover it automagically or in a more controlled way through --from-template-file (whatever name makes sense) here.

only my 2 cents on this: For func we also thought about having the template in the func/kn-plugin-func repot, but decided to keep this template in the hack repo, as that way, we have one single place to maintain the production Dockerfiles (/templates) and don't have to do this in multiple repos.
For the version issue: I think we need to cut version branches on hack repo anyhow at some point, as for example the generator for the Konflux manifests should not target all versions always.

[mgencur]

I don't want to every grow embeded templates

I don't see a problem adding another embedded template in the hack repo. So far we have only the following ones:

BuildImageDockerfile.template
DefaultDockerfile.template
FuncUtilDockerfile.template
SourceImageDockerfile.template

The number of custom templates will NOT grow indefinitely. We have just a few.
The single place to maintain production Dockerfiles is good. We can also easily add specific OWNERS (like Rudy or Kaustubh) for this single folder with templates and let them control what goes in the product.
So far the production dockerfiles have been kept in a single place (in gitlab).