-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inherit with override for pathFilter #1042
Comments
It seems reasonable for an inheriting |
That’s the only solution I could think of myself as well.
I might be interested in contributing this feature myself but have found a way to live with it for now and am swamped at the moment. So I’ll probably not be able to pick it up until after summer. Also, it may turn out too technical for me but I guess time will tell.
If you or others should find time and energy to have a go at it, please don’t wait for me. 😉
From: Andrew Arnott ***@***.***>
Sent: 21. maj 2024 20:41
To: dotnet/Nerdbank.GitVersioning ***@***.***>
Cc: Thomas Ravkilde ***@***.***>; Author ***@***.***>
Subject: Re: [dotnet/Nerdbank.GitVersioning] Inherit with override for pathFilter (Issue #1042)
It seems reasonable for an inheriting version.json to be able to override pathFilter rather than only append to its list. I'm not sure the best way to express this in version.json, but lacking a better idea, maybe add a pathFilterInherit bool property to the schema that is only allowed when inherit: true is set.
Are you interested in contributing this feature yourself?
—
Reply to this email directly, view it on GitHub<#1042 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWKBCKCPWO5SLSG5Z2UJAOTZDOIMHAVCNFSM6AAAAABF4Q77A6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGIZDQNJTGM>.
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>
|
I also ran into the exact same issue, but I'm thinking a simpler more general fix would be the following:
I cannot think of any instance where allowing so would make sense anyway (but maybe that's my limited imagination). So as an example, in a mono-repo, if you have three projects, each with their own With my suggested change, we could still add Would love to hear feedback on this, e.g. if there is a flaw in my reasoning. |
I have a VS solution with a number of projects. Most of them should share the same version but two need to be separate from the others, and each other, due to third-party integration demands (the point mainly being that they should not be version-bumped unless something has very specifically been changed in their projects).
To make everything more simple to maintain, I'd like to use
"inherit": "true"
and just set theversion
andpathFilter
in those two projects. However, it appears thatpathFilter
is concatenated when inheriting parentversion.json
info, which makes path filtering behave somewhat unintuitively.Right now have to exclude
pathFilter
in the parentversion.json
and then have one in every project that lists every folder that needs to be included by NB.GV, Preferably, I'd like to have a parentversion.json
with"pathFilter": [ ":/", "!separateRepo2", "separateRepo2 ]
or similar and just have"pathFilter": [ "." ]
for the two separate children.This sample should illustrate the point: sample.zip
The text was updated successfully, but these errors were encountered: