Open Stack

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.

> 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