NuKeeper for automated NuGet Package Reference Updates on Build Servers
Last week I looked at "dotnet outdated," a super useful .NET Core Global Tool for keeping a project's NuGet packages up to date. Since then I've discovered there's a whole BUNCH of great projects solving different aspects of the "minor version problem." I love this answer "Why?" from the NuKeeper (inspired by Greenkeeper) project with emphasis mine. NuKeeper will check for updates AND try to update your references for you! Why not automate the tedious!
NuGet package updates are a form of change that should be deployed, and we likewise want to change the cycle from "NuGet package updates are infrequent and contain lots of package changes, therefore NuGet package updates are hard and dangerous..." to "NuGet package updates are frequent and contain small changes, therefore NuGet package updates are easy and routine...".
Certainly no one is advocating updating the major versions of your dependent NuGet packages, but small compatible bug fixes come often and are often missed. Including a tool to discover - and optionally apply - these changes in a CI/CD (Continuous Integration/Continuous Deployment) pipeline can be a great timesaver.
Why do we deploy code changes frequently but seldom update NuGet packages?
Good question!
NuKeeper
NuKeeper is a .NET tool as well that you can install safely with:
dotnet tool install --global NuKeeper
Here it is running on my regularly updated podcast website that is running ASP.NET Core 2.1:
Looks like three of my packages are out of date. NuKeeper shows what version I have and what I could update to, as well as how long an update has been available.
You can also restrict your updates by policy, so "age=3w" for packages over 3 weeks old (so you don't get overly fresh updates) or "change=minor" or "change=patch" if you trust your upstream packages to not break things in patch releases, etc.
NuKeeper is picking up steam and while (as of the time of this writing) its command line parameter style is a little unconventional, Anthony Steele and the team is very open to feedback with many improvements already in progress as this project matures!
The update functionality is somewhat experimental and currently does 1 update per local run, but I'm really enjoying the direction NuKeeper is going!
Automatic NuGet Updates via Pull Request
NuKeeper has a somewhat unique and clever feature called Repository Mode in that it can automatically issue a Pull Request against your repository with the changes needed to update your NuGet references. Check out this example PullRequest!
Anthony - the lead developer - points out that ideally you'd set up NuKeeper to send PRs for you. Automatic PRs are NuKeepers primary goal and use case!
Again, it's early days, but between NuKeeper and "dotnet outdated," I'm feeling more in control of my package references than ever before! What are YOU using?
Sponsor: Scale your Python for big data & big science with Intel® Distribution for Python. Near-native code speed. Use with NumPy, SciPy & scikit-learn. Get it Today!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Tom Kerkhove
> When installing packages into projects using the PackageReference format, NuGet adds references to a flat package graph in the appropriate file and resolves conflicts ahead of time. This process is referred to as transitive restore. Reinstalling or restoring packages is then a process of downloading the packages listed in the graph, resulting in faster and more predictable builds. You can also take advantage of wildcard (floating) versions, such as 2.8.*, avoiding expensive and error prone calls to nuget update on the client machines and build servers.
https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution
Floating versions also don't notify you about "bigger" updates to install, like major versions outside of your star-matched ones. NuKeeper creates PRs for you in this case as well and makes the change visible.
By all means, if floating versions cover your use case, use them! They're simpler and work without extra tools :-)
> Floating versions aren't 100% predictable - building the same source later might get a different version resolved and installed, because a new package update was published.
Good point, thanks =)
what's your opinion on the safety of package restore on dev and build boxes? It seems like sooner or later some repo ist going to get hijacked and malware deployed on your servers. Can we really accept that risk?
Thanks!
tobi
until nuget release lockfile for repositories we use paket for that
https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-packages
the real combo is have Fake + Paket
every single repo has a nightly that trigger a specific target on the Fake build
since “standard build” is in the same fsx, the auto update re-use “build and test” target
all we have to do is
- create a separated build (nightly update)
- removing the lock file
- run the “paket install”
- attempt to build
- run all tests
- if this fails then this “update build” is red meaning “a human need to fix a breaking change”
- if it works out (Fake build hs easy api for git) we commit the file changes
- we push
- for protected branch we create a pull request for review (or force merge for some repo)
it’s like 4 line to do that and a build if you allready uses fake (works the same for cake)
we just wait for nuget to release CMNP for repos
https://twitter.com/adgrv/status/1016436920547663877?s=21
Ultimately it makes you aware if you are drifting versions behind, or maybe have missed some security patches, while keeping you in control of what goes into your code base.
Recent I have Downloaded GTA San Andreas Highly Compressed For Pc and then suddenly it ask for Microsoft NET Update and it's failed every single time I tried.
Comments are closed.