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
