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
Add path filtering support to version.json #399
Conversation
@AArnott mind giving this another review? I've added some tests now and I'm happy that it's working as expected. |
|
@AArnott this is ready for review when you get a moment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
@AArnott Did you get any time to read over this again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Your changes look pretty good, but I have a couple concerns which I've shared in comments.
I found that if I set a path filter to the current directory as The only way to monitor the current directory is to set its absolute path, which is kind of annoying, since it's nice to have a set of path filters that don't have hardcoded directory names that I can copy around to all the separate projects in the repo, like:
|
@shana I find that surprising. There is already a test Can you confirm that you're definitely seeing this problem as you describe? |
Hi @AArnott - sorry for taking so long to get back to you. I think I've covered all of your review comments - I've left a couple of them unresolved as I'm still waiting for a response from you on that. When you get a moment I think this is ready for re-review, thanks. |
@saul Now I can't reproduce it anymore. It's really confusing. It might be some cached state in the dotnet build server itself - build tasks dlls don't get unloaded between builds, and if one project is using one version of a build task and another project another version, it causes all kinds of horrible build failures. I'm having to shutdown the build-server every time I switch projects, so maybe that's what's happening... 😕 |
Just FYI I'm hoping to review this in the next few days. My vacation has started so I'm catching up on OSS repo work. |
OK, these changes look good. Thanks for thoroughly addressing my concern about respecting filters at each individual commit. My only remaining concern is perf of the Do you want to try resolving this? If not, I will try to find time over the next couple weeks. |
dc5930e
to
ca081cf
Compare
Thanks for looking at this again @AArnott. I'm away from a dev machine for the holidays so can't contribute in a meaningful way until January. I'm happy to resolve the perf concerns when I return (unless you have some free time before then). Another thing that crossed my mind which needs resolving (and testing) is invalid |
I don't think I'm too concerned about invalid paths. If the json can't parse we throw as well. People need to edit any commits that introduce a failure, so they are unlikely to ever push such commits in the first place. |
@AArnott I've implemented a partially working cache, but I'm having some problems. The cache (as written) assumes that the object returned by With this in mind there are a couple of options:
I'll implement the 1st option with MemberwiseClone so you have something to review that works and implements your comments above. However, I personally think that the 2nd option (no caching) is better as it's introducing complexity and brittleness for what I imagine will be very little gain. Thanks |
My concern about caching is that without it, You're adding another call to I'll take a look at what you've done though and see how we can best mitigate it. |
I replaced your cache work with something simpler that I think will do the trick. |
Oh whoops. I forgot about documentation. Can you write it up, @saul? |
I've written documentation for this - let me know what you think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Thanks.
Do you mind if I squash some of these commits before merging? It looks a bit noisy. :) |
Never mind. I wouldn't want to squash all the commits and I guess there was a merge in there, which makes squashing certain commits a bit harder. |
Any chance we could get a fresh beta release on to NuGet so we can start using this? Thanks! |
3.1.51-beta on its way to nuget now. |
@saul Is it necessary to have a version.json in the monorepo root? I've a monorepo with these folders:
I've configured my version.json in any subdir like this.
An update / add in any of the subfolders leads to a new version printed out by
For example: Afterwards i tried Is this the expected behaviour or is it an configuration fault? |
Ya, I guess we'd call this by design behavior. The path filters only keeps the version height value from incrementing from irrelevant changes. Nothing was ever done to the git commit that shows up for "non-public" releases to make it show the last commit that changed within that path filter. |
Goes part of the way to solving #160 (superseding #223 which has been quiet for most of the year).
Opening this now in a WIP state to get early feedback.
This PR adds a new
pathFilters
property toversion.json
. The array defines the paths to include in version height calculations. If a commit does not affect any path inpathFilters
, it does not increment the version height. This feature is entirely opt-in - ifpathFilters
is not defined, NB.GV calculates version height as it previously did.Todo:
Closes #160