GitHub help with dependency management

This is very useful:

I am building an application that comprises multiple repos. I continue to procrastinate on whether using multiple repos vs. a monorepo was a good idea but, an issue that I have (had) is the need to ensure that the repos’ contents are using current|latest modules. GitHub can help.

Most of the application is written in Golang with a smattering of Rust and some JavaScript.

Aside Even though I’m more proficient with Golang, I want to become more proficient in Rust and I contemplated trying to write the entire application in Rust. However, because I use many Google services and because Google does not yet provide Rust SDKs for its services (gRPC based offerings aside), I think I dodged some bullets using Golang.

Earlier this week, I decided to inventory the application’s repos by key dependency, i.e. which repos use e.g. google.golang.org/grpc. There are less than 10 repos and I keyed the result to less than 25 modules. So, not an insurmountable problem. Interestingly, a chunk of my dependencies are, of course, the app’s other repos. I pause every time I think about this, worrying about circular depdenencies and whether, if I touch one repo, I’ll spend the week recursively upgrading all the others!

Go Modules @latest

One challenge I continue to have with Go Modules is whether I should publish releases on GitHub. If I publish a (Go Module) as a release, then I can reference it consistently in go.mod:

module github.com/me/some-repo

go 1.17

require (
	github.com/me/some-other-repo v0.0.8
)

But, of course, whenever I bump one of some-other-repo’s depedencies, I should also create a release and then I need to trawl through its dependents and update their references to it.

The alternative appears to be (!?) not publishing releases on these internal module dependencies and letting @latest be the mechanism for always grabbing the most recent version.

Test

Create 2 repos and depend one on the other, then bump the version of one by making a commit, then:

1. Confirm that VS Code finds the update
2. Confirm that Dependabot (see below) finds the update

I think if both those things happen, I’ll delete all my releases and just stick to this more natural approach (for now). I always appreciate feedback.

Dependabot

GitHub has a very useful tool called Dependabot.

NOTE So there’s the original Dependabot and there’s the version deployed to GitHub and the two aren’t the same so, take care when viewing the documentation.

By committing a Dependabot spec|config file to your repos, you can configure GitHub to check code dependencies for you (Golang, JavaScript, Python, Rust etc. etc.). See Supported repos and ecos. You can either commit the file (.github/dependabot.yml) manually or, if you browse “Insights” (https://github.com/OWNER/REPO/pulse), “Dependency Graph”, then “Dependabot” (https://github.com/OWNER/REPO/network/updates), if not already configured, the GitHub UI will help guide you to committing the file.

version: 2
updates:
- package-ecosystem: "github-actions"
  directory: "/"
  schedule:
    interval: "daily"
- package-ecosystem: "gomod"
  directory: "/"
  schedule:
    interval: "daily"

In the example above, taken from github.com/DazWilkin/gcp-exporter, Dependabot is configured to check GitHub Actions and Golang Modules for updates.

I’ve also been enabling: “Dependency graph”, “Dependabot alerts” and “Dependabot security updates” via each repo’s “Settings”, “Security & analysis” page (https://github.com/OWNER/REPO/settings/security_analysis)

The screenshot at the top of the post, shows Notifications for this repo that I received this week for this week:

NOTE The Notification includes a reference (#14) to the PR in the repo that it created and that will apply the proposed change.

Clicking on any of the Notifications takes you to the PR created by Dependant so you can view the changes needed to bring the repo back into alignment.

For Golang, go.mod is being tracked by Dependabot and PRs created by it update go.mod and go.sum.

A natural next step is to trigger a build and, GitHub Actions, can be configured to make this happen.

It’s rather awesome.

It tends to happen that multiple changes occur and so I’ve been manually representing the changes proposed by Dependabot in my code to batch them up into one commit but, the recommended approach is to accept the PRs and let build|test steps ensure you’re not breaking anything.

GitHub’s Notifications tab is well-thought-through and you can filter the list easily by specific repos, by status (e.g. Assigned) by Unread etc. etc. You can also configure the Notifications to be emailed but, thus far, I’m finding the Notifications dashboard to be sufficient. You can also view the Notifications dashboard on the (Android) GitHub app.

• Github
• Modules
• Golang
• Dependencies
• Dependabot