lcitool/manifest: eliminate redundant container rebuilds

Currently we rebuild containers on every pipeline that is run.

We only ever keep one tag 'latest' per container in the
registry, regardless of branch. This is done to avoid filling
the registry for per-branch tags. The cost is that we must
rebuild the container on every branch push, since the current
'latest' tag might reflect an unrelated branch. The use of a
single tag also creates a race if pipelines from different
branches get triggered concurrently. The cost is somewhat
mitigated by using layer caching during build.

Historically this was handled the same way for forks and
upstream, but for upstream it is overkill. We don't make use
of CI against anything except the default branch, so the
content of the 'latest' tag always reflects current HEAD.

Given this there are only three cases where the upstream needs
to re-build containers

  - The Dockerfile / container-template.yml files changed
  - To pick up new packages published by the distro
  - A project member deleted a container from the registry

IOW, in upstream:

  - Most push events don't need to rebuild the 'latest' tag,
    only those with relevant file paths changed.

  - Only certain scheduled pipelines need to trigger a
    container rebuild. One a week is fine.

  - Manually triggered pipelines may need to rebuild

This patch set rules against the .container_job template to cut
down on jobs in upstream. To force the container builds in a
pipeline, the LIBVIRT_CI_CONTAINERS=1 variable should be set.

When updating across this change, project admins will need to
setup a scheduled job todo the weekly container rebuild.

Since the container build jobs will not exist in certain scenarios,
we now need to make the deps in the build jobs optional.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

0 files changed, 0 insertions, 0 deletions