Has anybody seen a project which has automated dependency updates?
I’m thinking about a nightly CI job which checks the package for updates in its dependencies. Maybe only minor-version updates to be conservative and assuming semver. It updates all dependencies and runs a (hopefully extensive) test suite. If the tests pass, the updates are committed to the repo. Next morning, all developers work with the new version (unless they work on an older branch).
I mostly have a mid to large company with a manyrepo approach in mind. However, I could also envision an Open Source community like Rust using this for applications (libraries usually try to be flexible with their dependencies anyways).
Of course, the burden is on the test suite. If you rely on manual tests for such version updates, this is not possible.
I would never ever use something like that. When I update dependencies, I generally try to check each update to see what has changed. This is where using a lot of dependencies becomes expensive, because it takes more work to update them.
I don’t really see this process bring automated, unless a web-of-trust like thing got popular. But I’m not holding my breath. :-(
There’s an existing open source tool called renovate that is highly configurable and supports a lot of platforms and package managers: https://github.com/renovatebot/renovate
I installed this this week for our local gitlabci infrastructure. Added it to 2 projects thus far via a yaml partial include. Working great so far.
Thanks for sharing that. I really like the idea. I wonder how hard it’d be to make it propose its patches using git-send-email instead of pull requests/merge requests.
I’ve used Dependabot before. GitHub then purchased them and made it a native feature. There are different ways to configure it, such as only opening PRs for fixes for security issues.
I’ve never used Dependabot’s automerge feature though. That’s a step too far for me. I want to at least skim the changelog to have an idea of the changes.
Same here. We also use Dependabot. It creates PRs with updates which are then tested in CI. We then just need to approve each update and merge it. I love how the PRs include the changelog for the update to make it easy to assess the risk.
If there were test cases to cover all scenarios I wouldn’t mind the auto-merge feature, but as it often happens, we’re not there yet.
Those PRs make sense.
Even if people (in my experience) eventually will merge without really looking at the diff, e.g. “let’s wait with merging this until after we’ve forked next week’s release” is a sane thing to say.
I use dependabot quite a bit. At my previous job we actually opted to automerge some select dependency updates. Minor versions for some dev/test deps. Did not become a problem during my time there.
No.
Yes. At my previous job I set up Dependabot PRs to be automatically merged for minor/patch updates if they passed CI. Major updates still required manual approval, which mostly meant reading the changelog.
The prerequisite, of course, was having good test coverage. Our unit test coverage was at 95+%, and we also had a solid set of browser level tests written in Cypress. We also had a QA engineer who was manually testing new features and bug fixes daily, so we’d quickly see if anything went wrong.
Before I left, we had also begun following this pattern for some huge projects whose coverage was not as good, but did have a lot of eyes on it daily. It seemed to be working well, but I didn’t get to see enough to have a firm conclusion about its usefulness/danger in that circumstance.
I have spent far to many hours of my life in jar hell (guava in Hadoop is a nightmare, but there are others… ) and would never use something like that. I want to know what goes into my dependency tree and update only if there is a reason (bugfix, security fix or feature I really really need).
There is a tool called Lorri which seems like something you should really look at:
https://www.tweag.io/blog/2019-03-28-introducing-lorri/
“When your channel updates, lorri watch automatically begins re-evaluating your project’s dependencies in the background, outside of your work shell. If you enter the shell before the evaluation completes, the last completed evaluation is loaded instead. When the new one is ready, your environment updates automatically.”
FWIW, I do the first part (CI run against the latest version of dependencies, both on each commit and weekly) on a couple of open source projects, to help detect incompatibility issues early.
I don’t auto-update. I usually update shortly after a release to give the new dependencies more exposure, in case something unexpected comes up.
Auto-updating is interesting. I can see how it could work for some specific projects/work environments, but I’d be very weary of too much churn/inconsistency, especially if they are external dependencies you don’t control (as opposed to internal ones which are within your project/company/etc. to manage and update).
Same here. We run scala-steward each hour for our different projects. Tests run automatically and we have a test harness (even if we should improve it, another story) But we don’t automatically merge the PRs. We want to be in control, more when we are close to a release date. But usually, we just check CI is green and the library involved in the update is not criticaland we merge it.
We do this at work on an hourly cadence for all dependencies, internal and external. If a project’s build failed after a
depupgrade, then a bot opens a PR for the team to resolve. It’s been far more helpful than harmful.At past jobs, I’ve setup a more conservative solution: a daily job that upgrades the dependencies and runs the test suite. It’s only when it fails that a PR is opened; that lets the team solve the dependency break and audit the rest, all in one go.