On Tue, May 1, 2018 at 10:02 AM, James E. Blair <cor...@inaugust.com> 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.

Emilien Macchi
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to