[libvirt PATCH v3 3/4] ci: Use GitLab container registry

[Daniel P. Berrangé]

On Wed, Jun 10, 2020 at 07:29:53PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-06-10 at 17:11 +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 10, 2020 at 05:34:13PM +0200, Andrea Bolognani wrote:
> > > +.container_default_job_template: &container_default_job_definition
> > > +  image: docker:stable
> > > +  stage: containers
> > > +  services:
> > > +    - docker:dind
> > > +  before_script:
> > > +    - export TAG="$CI_REGISTRY_IMAGE/ci-$NAME:$CI_COMMIT_REF_SLUG"
> > > +    - export COMMON_TAG="$CI_REGISTRY/libvirt/libvirt/ci-$NAME:master"
> > 
> > This is different to what we've done on all the other repos. I originally
> > used this, but noted that it results in a ever growing set of tags being
> > published in the container registry, as users will have a new branch name
> > for every piece of work. It also means you'll never a get a cache hit
> > from the user's registry across feature branches, though that is mitigated
> > to by fact that we'll consider the global cache too I guess.
> 
> We can have an additional
> 
>   --cache-from $CI_REGISTRY_IMAGE/ci-$NAME:master
> 
> to further reduce the possibility of getting a cache miss.
> 
> Note that you can configure an expiration policy for tags
> 
>   https://docs.gitlab.com/ee/user/packages/container_registry/#managing-project-expiration-policy-through-the-ui
> 
> but apparently it has to happen on a per-project basis instead of
> being something that you can set globally for your account.
> 
> Is having a lot of tags such a big problem? It seems like it's not
> unusual... See
> 
>   https://hub.docker.com/_/nginx?tab=tags
> 
> for an extreme example.
> 
> But yeah, maybe I'm overthinking this. If the pipeline produces the
> containers it consumes, then whether you label them as "latest"
> or "master" or "a0sd90lv_k1" doesn't really make any difference,
> because the next pipeline is going to build the containers again
> before using them.

I just never much like the idea of things growing without bounds,
even if someone else is paying for storage.

> There is still one scenario in which reusing the same name could lead
> to unwanted results, however, and that is when two or more pipelines
> are running at the same time. Right now this is allowed, but by
> using resource groups
> 
>   https://docs.gitlab.com/ee/ci/yaml/#resource_group
> 
> we should be able to prevent that from happening.

NB, running multiple pipelines in parallel is only a problem if those
pipelines actually contain changes to the dockerfile recipes. Otherwise
the rebuild of container images is essentially a no-op.


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