[email protected] (James E. Blair) writes: ... > The Changes > =========== > > I believe the following changes will address all five problems and > achieve both design goals: > > a) Apply inheritance at the same time as variance > > Rather than applying inheritance at configuration time, apply it at the > time the job is frozen before being run. We can perform a depth-first > traversal up the hierarchy of parents, applying all of the matching > variants at each level as we return down. With the following graph > (where lines indicate parent relationships): > > 0 base > / \ > 1 devstack 2 devstack 4 altbase > \ / | > 3 tempest 5 tempest > / \ > 6 foo 7 foo > > Would have the following jobs applied in order: > > 0 base, 1 devstack, 2 devstack, 3 tempest, 4 altbase, > 5 tempest, 6 foo, 7 foo > > b) Add an implicit branch matcher to the master branch > > Generally this will add clarity to projects with multiple branches, > however, if we always add the an implicit branch matcher, then it makes > it difficult to use repos like zuul-jobs to define jobs that run > everywhere. So do this only if the project has multiple branches. If > the project only has a single branch, omit the implicit branch matcher. > > c) Add a config option to disable the implicit branch matcher > > There are some times when an implicit branch matcher on master may be > undesirable. For example when tempest was becoming branchless, it had > multiple branches, but we would have wanted the jobs defined on master > to be applicable everywhere. Or if, for some reason, we wanted to > create a feature branch on zuul-jobs. For these cases, it's necessary > to have an option to disable the implicit branch matcher. We can add a > new kind of configuration object to zuul.yaml, for example: > > - meta: > implicit-branch-matcher: False > > Which would be intended only to apply to the current branch. Or we > could add an option to the tenant config file, so the admin can indicate > that a certain project should not have an implicit branch matcher > applied to certain branches. > ... > > (d) Remove the implicit run playbook > > This is not required to solve any of the problems stated, however, it > does make the solution to problem (4) even more explicit. > > Moreover, despite being an initial proponent of the implicit playbook, I > have found that in practice, we have so many jobs that do not have > playbooks at all (i.e., we're making heavy use of inheritance and > variance) that it is becoming difficult to determine where to look for a > job's run playbook. Declaring the run playbook explicitly will help > with discoverability.
These changes have been implemented and merged into the feature/zuulv3 branch. I also included a change to accept file extensions on playbook paths, with the intention that we will deprecate the option to omit extensions. -Jim _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
