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

Andrea Bolognani abologna at redhat.com
Wed Jun 10 17:29:53 UTC 2020


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.

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.

> > +    $LCITOOL dockerfile $host libvirt >ci-$name.Dockerfile
> 
> In all the other projects we've just used $host.Dockerfile.
> 
> If we really want to eliminate the "libvirt-" prefix, then it is probably
> better to modify lcitool to remove this prefix. It is a pretty pointless
> name prefix considering the targets are used for non-libvirt projects too.

I agree that it looks silly at this point, and I've idly considered
getting rid of it, but as long as we keep the CentOS CI environment
running it needs to stay because workers there are not namespaced,
so the prefix can't be removed.

In the meantime, I can skip the pre-processing and keep this more
consistent with what goes on in the other repositories.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list