search

dotnet / Nerdbank.GitVersioning

Stamp your assemblies, packages and more with a unique version generated from a single, simple version.json file and include git commit IDs for non-official builds.
https://www.nuget.org/packages/Nerdbank.GitVersioning
MIT License
1.36k stars 166 forks source link

Inherit with override for pathFilter #1042

Open thomas-ravkilde opened 6 months ago

thomas-ravkilde commented 6 months ago

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 the version and pathFilter in those two projects. However, it appears that pathFilter is concatenated when inheriting parent version.json info, which makes path filtering behave somewhat unintuitively.

Right now have to exclude pathFilter in the parent version.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 parent version.json with "pathFilter": [ ":/", "!separateRepo2", "separateRepo2 ] or similar and just have "pathFilter": [ "." ] for the two separate children.

This sample should illustrate the point: sample.zip

AArnott commented 4 months ago

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?

thomas-ravkilde commented 4 months ago

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 GitHubhttps://github.com/dotnet/Nerdbank.GitVersioning/issues/1042#issuecomment-2123228533, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWKBCKCPWO5SLSG5Z2UJAOTZDOIMHAVCNFSM6AAAAABF4Q77A6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGIZDQNJTGM. You are receiving this because you authored the thread.Message ID: @.**@.>>

AnorZaken commented 1 day ago

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 version.json + one more in the repo-root that all the others inherit from.
Now let's say one of those three projects is called Foo and it has the same requirements as described in this issue: changes made in Foo should not bump the version of the other projects.

With my suggested change, we could still add !/Foo to the pathFilter of the root version.json and when nbgv parses the version-file inside of /Foo/version.json it should simply be smart enough to know that inheriting /!Foo wouldn't make much sense so it ignores that specific entry (or at least I assume so?).

Would love to hear feedback on this, e.g. if there is a flaw in my reasoning.
(An alternative way of describing this rule would be "Versioning of a project will always include the directory where the project file resides.")