Open Stack

Doug Hellmann <doug at doughellmann.com> writes:

> In the discussion yesterday, and in the emails today, you've implied
> that there is an ordering to job definitions beyond inheritance. Is that
> discovery order documented somewhere? If not, is it simple enough to
> describe in a few sentences here? Are repositories scanned in a
> particular order, for example? Or is it based on something else?

There's some discussion of it here:

https://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#job

  When Zuul decides to run a job, it performs a process known as
  freezing the job. Because any number of job variants may be
  applicable, Zuul collects all of the matching variants and applies
  them in the order they appeared in the configuration. The resulting
  frozen job is built from attributes gathered from all of the matching
  variants. In this way, exactly what is run is dependent on the
  pipeline, project, branch, and content of the item.

Because top-level job variants may only be defined in the same project
(so that one project may not alter the jobs defined by another project),
the order that the repos are loaded doesn't matter for this; only the
order that branches are loaded within a repo.  That's not specified by
the documentation, though it is currently 'master' followed by others in
alphabetical order.

The proposed changes would reduce the importance of that, since master
will have an implied branch matcher, meaning that by default, jobs in
master won't have an effect on other branches.  I'd probably still leave
the order the same though, in case someone wanted to override that
behavior.

In practice, and especially with the proposed change to have an implied
branch matcher on master, the ordering aspect is most likely to be
visible when a user adds several variants of a job in the same file.

The order that the repos themselves are loaded is important, however, in
inheritance.  They are loaded in a defined order (the order they appear
in the main.yaml tenant configuration file), and currently, a job may
only inherit from another job which has already been defined.  So we
manually put more "general-use" projects (e.g., devstack, tempest)
earlier in the config.  I would characterize this as an oversight, and
was planning on fixing it soon regardless, however, the proposal to
perform late-binding inheritance will solve it as well (since the
inheritance path would be determined when the job is run, well after all
the configuration is loaded).

There's some more discussion of the repo loading order here:

  https://docs.openstack.org/infra/zuul/feature/zuulv3/admin/tenants.html#attr-tenant

-Jim