On Wed, May 2, 2018 at 11:21 PM, James E. Blair <cor...@inaugust.com> wrote: > Joshua Hesketh <joshua.hesk...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev