Open Stack

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

Thanks,
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180501/ef678df5/attachment.html>