Open Stack

On Tue, May 1, 2018 at 1:23 PM Emilien Macchi <emilien at redhat.com> wrote:

> 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
>

I agree,
Proposal #2 makes the most sense to me and seems more straight forward in
that you have the ability to override and that the project overriding would
need to handle both files and irrelevant-files from scratch.

Nice write up



> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180501/36cdac7c/attachment.html>