The Dependabot team writes about automated dependency update pull requests, Ruby tooling, Bundler resolution, and security disclosures.
HN commenters recommend Dependabot for keeping dependencies current and praise its compatibility score, though one notes noisy alerts and hard-to-maintain Node dependencies.
There’s a difference between these two senses of “automatic”, though.
An “automatic” update of a language-ecosystem build-time dependency package, is still curated by your (not usually fully-automatic) release-management process, like any other codebase change. With full CI/CD automation, some bot (e.g. https://dependabot.com/) notices that a dep has updated, and “proposes” a PR that updates your project’s lockfile; your CI buildbot then notices the new PR, and tries building that branch to see whether it compiles and all the tests pass; and, if everything looks good, it merges the PR into the main development branch. Even then, it’s now just merged into the ‘develop’ branch, and is not necessarily going to be a part of a cut release yet. A CD bot may put it into a QA environment from there; divert a percentage of traffic to it (ala https://github.com/github/scientist); and then maybe eventually make the call that it’s not hurting your metrics, and so switch the traffic fully over to it. But more often, there are usually humans in charge of that final cut-over switch, whoget to make a final call, before this kind of “automatic” update fully hits prod.
Whereas, with OS packages, there’s no CI/CD pipeline — the version number on the package (coupled with your auto-update config) is the “last line of defense” standing between the package and your production system. You can set up a mirroring QA environment that gets updates first; but this is effectively just “smoke testing”…
This is correct, using a commit hash is safer.
However, you'll sometimes want to update the commit hash after the action's maintainer releases new code. If you don't then you run the risk of running an old action that has vulnerable components or bugs.
The easiest workflow for that should be Dependabot's updater for GitHub actions:
https://dependabot.com/github-actions/
Has anyone tried that approach for GitHub actions?
You still need to review the action's code before you use it, and every time you update to a new commit hash. But this approach protects you from automatically running new malicious code pushed to master/re-tagged.
There are few github bots [1][2] that keep your fork up to date. They probably don't offer the exact workflow that you want, but you can always customise.
I'd assume that if GitHub notices that bots like these are popular, they'd think about incorporating it as a feature. In a way, this is what has happened with Dependabot [3] - IMO it's been so widely used that it made sense for GitHub to include it as a feature.
[1] https://github.com/backstrokeapp/server
[2] https://github.com/wei/pull
[3] https://dependabot.com/blog/hello-github/
You can do this with Dependabot [0], recently acquired by Github.
We use Dependabot, and I love it for our backend repositories, but anything with node dependencies ends up being easier to manually update (because there ends up being so many dependencies that get updated every day, that opening a PR for each one essentially launches a denial of service attack on our CI system)
[0] https://dependabot.com/
Isn't this already done by Dependabot[1]? I've been using it for some time with my JS/TS repos to keep my dependencies up-to-date. It's not the greatest as it sends alerts about vulnerabilities in devDependencies. But with automatic merge checks I only get an email that the issue has been fixed so it isn't the worst thing in the world.
[1] https://dependabot.com/
> It could still be an open platform, of course. Someone just needs to be able to do it better than Github. As Dependabot shows, that's absolutely possible.
Awkward, this literally happened today: https://dependabot.com/blog/hello-github/
(I agree with the thrust of your comment; I just think the timing here is funny.)