[libvirt-jenkins-ci PATCH] dco: build and publish a container image for DCO check

[Andrea Bolognani]

On Wed, 2020-04-08 at 12:54 +0100, Daniel P. Berrangé wrote:
> This builds a container image containing the DCO checking script.
> It is then published at:
> 
>    registry.gitlab.com/libvirt/libvirt-jenkins-ci/check-dco:master
> 
> from where it can be used in all other project repositories. This
> avoids having to copy the check-dco.py script into every repo
> when we want to make changes to it.

So the idea is that the current dco job in, for example, libvirt,
will become

  dco:
    stage: prebuild
    script:
      - /check-dco.py
    image: registry.gitlab.com/libvirt/libvirt-jenkins-ci/check-dco:master

and the same job will be added for all other projects, correct?

> +.build_container_template: &build_container_definition
> +  image: docker:stable
> +  stage: containers
> +  services:
> +    - docker:dind

TIL: dind means "Docker in Docker".

> +  before_script:
> +    - docker info
> +    - docker login registry.gitlab.com -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}

For those following along at home, these variables are set
automatically by GitLab:

  https://gitlab.com/help/ci/variables/predefined_variables.md

> +  script:
> +    - docker build --tag ${CI_REGISTRY_IMAGE}/${NAME}:${CI_COMMIT_REF_SLUG} -f ${NAME}/Dockerfile ${NAME}

The '-f ${NAME}/Dockerfile' part is unnecessary, because Dockerfile
is the default name 'docker build' looks for and it will already
enter the directory you provided (it wouldn't find the script
otherwise).

> +    - docker push ${CI_REGISTRY_IMAGE}/${NAME}:${CI_COMMIT_REF_SLUG}

I'm not super happy about returning to the image:master naming
convention, because most tooling around containers will expect the
tag name to be 'latest' and we had just recently managed to adopt it
throughout, but of course we need to make sure containers build off
branches do not overwrite the known good image built from master...

A more important question is whether this should live in
libvirt-jenkins-ci at all. In the long run the Jenkins stuff is going
to be dropped, and that would lead to the already pretty awkward name
becoming completely inaccurate.

libvirt-dockerfiles would be an obvious candidate right now, but as
we start moving generated Dockerfiles to the corresponding
repositories that's going to be abandoned and eventually removed.

I was going to suggest that, once the Jenkins stuff has been removed,
we could rename the repository to lcitool, but maybe we should call
it libvirt-ci instead? Or even just ci for that matter: we already
have a number of non-prefixed repositories, and if they contain
internal tools rather than projects that are intended to be released
and distributed I think that's perfectly fine and if anything
highlights the distinction.

> +++ b/check-dco/Dockerfile
> @@ -0,0 +1,6 @@
> +FROM centos:8
> +
> +RUN dnf -y install python3 git && \
> +    dnf -y clean all
> +
> +COPY check-dco.py check-dco.py

I suggest using an absolute path for the destination for clarity,
though it shouldn't actually make a difference.

Can we call the script "check-dco" without the .py suffix? The
language used is an implementation detail that users will not be
interested in.

-- 
Andrea Bolognani / Red Hat / Virtualization