On Tue, May 1, 2018 at 10:02 AM, James E. Blair <[email protected]> wrote: [...]
> Okay, let's summarize: > > Proposal 1: All project-template and project-local job variants matching > the item's branch must also match the item. > > * Files and irrelevant-files on project-template and project stanzas are > essentially combined in a set intersection. > * It's possible to further reduce the scope of jobs, but not expand. > * Files and irrelevant-files are still independent matchers, and if both > are present, both must match. > * It's not possible to alter a job attribute by adding a project-local > variant with only a files matcher (it would cause the whole job to run > or not run). But it's still possible to do that in the main job > definition itself. > > Proposal 2: Files and irrelevant-files are treated as overwriteable > attributes and evaluated after branch-matching variants are combined. > > * Files and irrelevant-files are overwritten, so the last value > encountered when combining all the matching variants (looking only at > branches) wins. > * Files and irrelevant-files will be treated as a pair, so that if > "irrelevant-files" appears, it will erase a previous "files" > attribute. > * It's possible to both reduce and expand the scope of jobs, but the > user may need to manually copy values from a parent or other variant > in order to do so. > * It will no longer be possible to alter a job attribute by adding a > variant with only a files matcher -- in all cases files and > irrelevant-files are used solely to determine whether the job is run, > not to determine whether to apply a variant. > > I think both would be good solutions to the problem. The key points for > me are whether we want to keep the "alter a job attribute with variant > with a files matcher" functionality (the "rebuild_index" example from > above), and whether the additional control of overwriting the matchers > (at the cost of redundancy in configuration) is preferable to combining > the matchers. > In the case of TripleO, I think proposal 2 is what we want. We have stanzas defined in the templates definitions in openstack-infra/tripleo-ci repo, but really want to override the file rules per repo (openstack/tripleo-quickstart for example) and I don't think we want to have them both matching but so the last value encountered would win. I'll let TripleO CI squad to give more thoughts though. Thanks, -- Emilien Macchi
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
