Building GitHub Action That Ended My Update Nightmares

Today, I finally tackled a problem that's been quietly nagging at me for months: keeping dbt_utils packages up to date across all our data projects. If you work with dbt, you know the drill—every time a new dbt_utils release drops, it's a scramble to update packages.yml in every repo, open a bunch of pull requests, and hope nothing slips through the cracks. It’s repetitive, tedious, and honestly, not the kind of work that sparks joy.

As our data platform grew, so did the number of places I had to make these updates. I’d find myself thinking, “Did I already update this repo? Wait, is this one still on an old version?” It was a recipe for inconsistency and wasted hours behind digging through every repository.

This is kind of a continuation of my last blog post, One Script, Many Repositories: Easy Refactoring, where I explored automating changes across multiple repositories. That experience inspired me to take automation a step further—this time, focusing on dependency updates with GitHub Actions.

So today, I decided enough was enough. I wanted a solution that would:

• Save me (and my team) from the endless cycle of manual updates.
• Keep all our projects reliably on the latest, tested version of dbt_utils.
• Still let us review changes before merging—no surprises.

After some tinkering, I built a GitHub Actions workflow that checks for new dbt_utils releases and automatically opens a pull request with the update. Now, instead of chasing updates, I get a friendly notification and a ready-to-review PR. It’s a small change, but it feels like a big win for my sanity—and for our platform’s reliability.

If you’re facing the same headache, I’ve open-sourced the workflow and script. You can find everything (plus setup instructions) at stephaniec2020/dbt-utils-autoupdate-action. Fork it, adapt it, or send a PR—hopefully, it saves you as much time as it’s saving me.