Open Stack

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



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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180502/5ee727ed/attachment.html>