Re: [libvirt PATCH v3 3/4] ci: Use GitLab container registry
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-pro...
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