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