[PATCH] ci: Refresh generated files

Daniel P. Berrangé berrange at redhat.com
Fri May 27 12:50:06 UTC 2022


On Fri, May 27, 2022 at 02:47:20PM +0200, Martin Kletzander wrote:
> On Fri, May 27, 2022 at 12:45:17PM +0100, Daniel P. Berrangé wrote:
> > On Fri, May 27, 2022 at 01:37:10PM +0200, Martin Kletzander wrote:
> > > Notable changes:
> > > 
> > > * 'lcitool manifest' now generates absolute include paths
> > > 
> > > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> > > ---
> > > Pushed under the 'build-breaker' and 'just-ci-update' rules (just in case the latter also exists).
> > 
> > Unfortunately this change is not needed and won't fix the
> > reported build problem. We need the .gitlab-ci.yml to
> > add 'optional: true' to the 'needs:' in the failing jobs.
> > 
> 
> It took me a while to understand it, but what you're saying is that the
> container jobs are not even defined if the dockerfiles are not changed
> and hence the dependency cannot be resolved?  If that's it then good, if
> not, then I'm baffled once again.

Essentially yes.

Consider the rules in .container_job:

  rules:
    - if: '$CI_PROJECT_NAMESPACE == "libvirt" && $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      when: on_success
      changes:
       - ci/gitlab/container-templates.yml
       - ci/containers/$NAME.Dockerfile
    - if: '$CI_PROJECT_NAMESPACE == "libvirt" && $LIBVIRT_CI_CONTAINERS == "1"'
      when: on_success
    - if: '$CI_PROJECT_NAMESPACE == "libvirt"'
      when: never
    - when: on_success


these are processed in-order and the first match wins. In this
case we're hitting the 3rd rule. The 'when: never' clause causes
the job to cease to exist in the current pipeline execution, and
thus we get the dependency problem you reported.

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


More information about the libvir-list mailing list