GitHub is at the heart of how I do work, and Dependabot is one of the core tools. Even before we started using OpenSSF Scorecards, which pushed us to pin dependencies, Dependabot was something we used a lot to ensure that things were up to date.

But, Dependabot isn’t perfect, and looking at the discussion threads involving those who support it, there might be some underlying problems that are stopping things from being improved. That of course leaves the door open to new tools, which can hopefully do what Dependabot does and more (or perhaps augment Dependabot functionality – maybe I just need a bot for my bot).

Rollups

For many package managers I need to configure Dependabot for each location that it will find files defining dependencies. If I have Dockerfiles in four places then I’ll get four pull requests (PRs), even if the FROM line is the same across them. Merging those PRs separately gets time consuming, as each merge to trunk turns into a rebase for the next PR, and each rebase means another run through continuous integration (CI) tests.

Nobody wants to sit and wait for tests to run.

The workaround for this is to rollup the PRs. I can git checkout the first PR’s branch, and then git merge each of the subsequent PR branches. One approval, one run through CI, one merge that closes all the PRs at once.

But that’s a manual process. I’d much rather say (in PR #1234): @dependabot rollup #1235 #1236 #1237 and it can take care of the merges for me.

Of course all of the above would be less of an issue if we could configure Dependabot with lists of locations rather than have to repeat configs around single locations…

Class approval

We have the OpenSSF Scorecards action deployed to 13 repos, which means every time ossf/scorecard-action gets bumped that’s 13 PRs, and every time github/codeql-action/upload-sarif gets bumped that’s another 13 PRs. This quickly gets tedious.

What I’d like to do instead is one review (an instance of the class), which then automatically approves (and merges) all the others.

Dealing with Dependency Cascades

There are places in the Atsign code base where I’ve consciously decided not to pin dependencies, because every release results in a new Docker image, and every new Docker image would yield in a new SHA that has to be pinned against – a dependency cascade, which potentially becomes a dependency cyclone, only moderated by the Dependabot (typically daily) schedule.

Of course circular dependencies are a problem almost as old as using dependencies, and there’s no easy answer here; but I’d like to be able to define some behaviours e.g. these hashes come from the last release, don’t create another release when they’re merged to trunk, or we’ll be at this forever.