Doug Hellmann <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
