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

[Daniel P. Berrangé]

On Wed, Apr 08, 2020 at 04:54:17PM +0200, Andrea Bolognani wrote:
> 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

Since they clearly have issues, we shouldn't follow their bad
example.

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

I consider those few cases in libvirt to be a mistake, but since
we don't actively use those repos I didn't care about them.

This naming clash has hit me several times, so I don't want to
make it worse by creating super generic names for libvirt repos.

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

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