Open Stack

On Wed, May 2, 2018 at 11:21 PM, James E. Blair <corvus at inaugust.com> wrote:
> Joshua Hesketh <joshua.hesketh at gmail.com> writes:
>
>>>
>>> I think in actuality, both operations would end up as intersections:
>>>
>>> ================  ========  =======  =======
>>> Matcher           Template  Project  Result
>>> ================  ========  =======  =======
>>> files             AB        BC       B
>>> irrelevant-files  AB        BC       B
>>> ================  ========  =======  =======
>>>
>>> So with the "combine" method, it's always possible to further restrict
>>> where the job runs, but never to expand it.
>>
>> Ignoring the 'files' above, in the example of 'irrelevant-files' haven't
>> you just combined the results to expand when it runs? ie, A and C are /not/
>> excluded and therefore the job will run when there are changes to A or C?
>>
>> I would expect the table to be something like:
>> ================  ========  =======  =======
>> Matcher           Template  Project  Result
>> ================  ========  =======  =======
>> files             AB        BC       B
>> irrelevant-files  AB        BC       ABC
>> ================  ========  =======  =======
>
> Sure, we'll go with that.  :)
>
>>> > So a job with "files: tests/" and "irrelevant-files: docs/" would do
>>> > whatever it is that happens when you specify both.
>>>
>>> In this case, I'm pretty sure that would mean it reduces to just "files:
>>> tests/", but I've never claimed to understand irrelevant-files and I
>>> won't start now.
>>
>> Yes, I think you are right that this would reduce to that. However, what
>> about the use case of:
>>   files: tests/*
>>   irrelevant-files: tests/docs/*
>>
>> I could see a use case where both of those would be helpful. Yes you could
>> describe that as one regex but to the end user the above may be expected to
>> work. Unless we make the two options mutually exclusive I feel like this is
>> a feature we should support. (That said, it's likely a separate
>> feature/functionality than what is being described now).
>
> Today, that means: run the job if a file in tests/ is changed AND any
> file outside of tests/docs/* is changed.  A change to tests/foo matches
> the irrelevant-files matcher, and also the files matcher, so it runs.  A
> change to tests/docs/foo matches the files matcher but not the
> irrelevant-files matcher, so it doesn't run.  I really hope I got that
> right.  Anyway, that is an example of something that's possible to
> express with both.
>
> I lumped in the idea of pairing files/irrelevant-files with Proposal 2
> because I thought that being able to override them is key, and switching
> from one to the other was part of that, and, to be honest, I don't think
> people should ever combine them because it's hard enough to deal with
> one, but maybe that's too much of an implicit behavior change, and
> instead we should separate that out and consider it as its own change
> later.  I believe a user could still stop a the matchers by saying
> "files: .*" and "irrelevant-files: ^$" in the project-local variant.
>
> Let's revise Proposal #2 to omit that:
>
> 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.
> * 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.

This is limitation for this Proposal but i am not sure how many use
case of this features. I have not seen till now in jobs.
>

Yes, Proposal#2 looks good for nova use case [1] also where
integrated-gate templates job needs to be controlled by nova pipeline
definition mainly for 'irrelevant-files'. This approach gives benefit
of Easy to read from one place that this job is controlled by these
value of overridden var ('files', 'irrelevant-files').


-gmann

>> Anyway, I feel like Proposal #2 is more how I would expect the system to
>> behave.
>>
>> I can see an argument for combining the results (and feel like you could
>> evaulate that at the end after combining the branch-matching variants) to
>> give something like:
>> ================  ========  =======  =======
>> Matcher           Template  Project  Result
>> ================  ========  =======  =======
>> files             AB        BC       ABC
>> irrelevant-files  AB        BC       ABC
>> ================  ========  =======  =======
>>
>> However, that gives the user no way to remove a previously listed option.
>> Thus overwriting may be the better solution (ie proposal #2 as written)
>> unless we want to explore the option of allowing a syntax that says
>> "extend" or "overwrite".
>>
>> Yours in hoping that made sense,
>> Josh
>
> As much as anything with irrelevant-files does, yes.  :)
>
> -Jim
>

..1 https://bugs.launchpad.net/nova/+bug/1745431 ,
https://bugs.launchpad.net/nova/+bug/1745405

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