On Wed, Apr 08, 2020 at 04:21:31PM +0200, Andrea Bolognani wrote:
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?
Yeah, exactly.
+.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).
Oh yes.
+ - 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...
We could have conditional logic that changes it to "latest" if $CI_COMMIT_REF_SLUG == "master"
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.
Yeah, I was about to suggest that we just rename this to "libvirt-ci", and accept the short term pain for people with broken URLs. It is highly desirable to avoid very short, generic names like "ci", because when you fork a repo into your own namespace, the repo names must match and thus you risk a clash if you've forked a repo called "ci" from an unrelated project.
+++ 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.
Sure, we can drop the .py Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|