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(a)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 :|