Updating dependencies in Azure DevOps repos

Photo by rawpixel.com from Pexels

Background

One problem we have as developers, is keeping on top of our dependency housekeeping. How often have you seen a repo with packages that are months, perhaps years, out of date? And how many times have you tried to update one or more, only to rage-revert after hours of hair pulling frustration? Updating these dependencies few and often is most definitely the way forward.

TL;DR

If you’d rather just dive in, simply import my azure-dependabot repo into your Azure DevOps project and follow the instructions in the README file. You’ll be generating PRs for outdated dependencies in no time at all.

What stopped me?

One thing that has caused me much head scratching, is the Azure Artifacts NuGet feed; a perennial thorn in my side that has led me to compromise my solutions on more than one occasion. The problem being the feed is public and requires authentication, rather than being accessible within a VPN with no authentication (for read access at least). This is obviously only a problem if your repo references packages in such a feed.

And then what?

The next stumbling block was much less obvious than the first, and ultimately required me to submit a PR to the dependabot-core repo itself. The script worked on my development machine, but not on a build agent; the commit relating to the dependency upgrade created by Dependabot was missing the author.email field. It seems the Azure DevOps API is able to deduce my email from my access token, but doesn’t use a placeholder when the Azure DevOps System.AccessToken is used, instead setting the author.email to empty. The problem was exacerbated as Dependabot expects all commits in a repo to have such a field and throws an exception if not.

What now?

  • The script above only targets a single repo; it makes perfect sense to extend this to multiple repos. This will be my first task on Monday morning.
  • I’ve previously contributed towards a consolidation feature in NuKeeper; I’d like to investigate if such a feature exists in Dependabot and potentially contribute if not. I find this useful for related packages that are published with the same build cadence. This would solve the problem where 2 related packages generate 2 PRs, both of which fail individually, but succeed when combined.
  • I’d like to investigate a workflow involving Pre-release packages; this would help me confirm downstream consumers are happy with knock-on changes by creating PRs along a dependency chain.

Summary

We have learnt how to integrate Dependabot directly into Azure DevOps, adding to an existing Pull Request workflow to automatically create PRs and run tests whenever a new version of an upstream dependency is published. If you don’t have something similar to Dependabot already, set it up and make life easier for you and your fellow developers.

Freelance Engineer, Architect, Problem Solver etc. https://twitter.com/acraven_dev