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

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.