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

[Andrea Bolognani]

On Wed, 2020-04-08 at 15:26 +0100, Daniel P. Berrangé wrote:
> 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:
> > > +    - 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"

If that logic doesn't end up being too complicated and hard to
maintain, I would certainly like that.

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

I think that boat has sailed already... If you look, for example, at

  https://github.com/kubernetes/
  https://github.com/kubevirt/
  https://github.com/kata-containers/

you'll see that a lot of the repositories living in those
organizations have pretty generic names, so much so that you can
already spot conflicts at first glance, plus as I said we have
stuff like

  https://gitlab.com/libvirt/hooks
  https://gitlab.com/libvirt/scripts

in our own organization already, so I wouldn't worry too much about
this.

Personally, what I usually do when cloning such a repository is
rename the clone of $org/$repo to $org-$repo right away and then I
never have to even think about it again. It's really not a big deal.

-- 
Andrea Bolognani / Red Hat / Virtualization