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@xxxxxxxxxx>
> > > ---
> > > 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 :|
