Missing support for ManagePackageVersionsCentrally
omer-za opened this issue · comments
When using ManagePackageVersionsCentrally as the model of package versioning then the affected doesn't know
which project is affected from a version change, it's crucial in case dependency upgrade will cause a CI break.
Hi @omer-za!
This happens with all "global" files or files that are not in the directory where the csproj file is located, but that do affect the build process, like .props or .targets.
It's kind of a known issue for me, but it should definitively be documented and we may be able to do something about it.
I would need to think a if there is other way than git diffing them, but what we do in our CI builds is to have a special step where we do a git diff of the files we consider "global" and trigger a complete build whenever those changes.
It would be awesome, when using central package version (which we do as well), to be able to understand which packages changed and which projects are affected based on the packages that changed instead of the files inside the project directory.
It's possible by extracting the changed packages and then enumerate all csproj files that contains references to those packages.
Yeah I think that could work, we could compare the old a new Directory.package.props and find all projects that are referencing those packages, those are the affected ones.
I would need to think a if there is other way than git diffing them, but what we do in our CI builds is to have a special step where we do a git diff of the files we consider "global" and trigger a complete build whenever those changes.
This is still required tho. There could be .props or .target files that would affect the build anyways
Yeah but those are less important in my opinion and rarely changes
Hey, I had a first stab at trying to implement this in #23 feedback appreciated!
Hi, we have implemented an initial version for detecting affected projects by changes to the Directory.Packages.props file.
Current implementation is not evaluating the Directory.Packages.props using MSBuild but uses a regex for understanding the file instead. In practice, if the Directory.Packages.props file contains conditional logic, for example, they will not be considered by dotnet-affected.
I'll create a separate issue to track the improvements to the algorithm.
A new preview version will be released soon (need to automate delivery so I can release more often)
Hi all. Just wanted to give an updated on this statement for any future reader:
Current implementation is not evaluating the Directory.Packages.props using MSBuild but uses a regex for understanding the file instead. In practice, if the Directory.Packages.props file contains conditional logic, for example, they will not be considered by dotnet-affected.
A change was made to support understanding conditions in Directory.Packages.props files. We have a test case to cover it.
Central Package Management support has been released in v2.2.0-preview an will come out of preview as soon as I confirm it is working properly in a production environment.