Dispatches¶

Bulk Delete GitHub Actions Workflow Runs

GitHub Actions accumulates workflow run history quickly. After a few months of active development, a busy repository can have thousands of runs: every push, every pull request, every scheduled job. Most of those runs are no longer useful, but the GitHub web interface only lets you delete one run at a time. If you want to clean up a large backlog, you need a different approach.

This post covers a one-liner that bulk-deletes all workflow runs for a repository using the GitHub CLI (gh) and jq.

CODEOWNERS: Automating Code Review Ownership

Most projects have a moment when someone merges a change to a critical file without the right people ever seeing it. Not because anyone meant to skip the review, but because nothing in the workflow made it obvious who should have been asked. A security-sensitive configuration file, a shared library that dozens of services depend on, a public API contract: all of them can drift in the wrong direction when ownership is implied rather than explicit.

A CODEOWNERS file solves that problem. It maps paths and patterns in your repository to the people and teams responsible for reviewing them. When someone opens a pull request or merge request that touches those paths, the platform automatically requests a review from the designated owners. No manual assignment required, no institutional knowledge needed, and no way to merge without the right sign-off if you enforce it with branch protection.

This post covers what a CODEOWNERS file is, how to construct one, and how to use it effectively in your repositories.

Renaming a Git Tag

Git does not have a rename command for tags. There is no git tag --move or git tag --rename. Tags are immutable references; once created, you cannot change the name of one without creating a new one and removing the old one.

That leaves developers in an awkward position when a tag carries the wrong name. You tagged v2.1.7 as release-2.1.7. The project switched from a release-X.Y.Z convention to vX.Y.Z. A typo slipped through before the push. Whatever the reason, the tag exists in both local and remote repositories, and it needs to be renamed.

The process takes four commands, and each one does a specific job.

Using dev_overrides for Local Terraform Provider Development

When you are building a Terraform provider, the default installation mechanism works against you. Every time you want to test a change, Terraform looks up the provider in a registry. That means you either publish a pre-release to the Terraform Registry on every iteration, configure a private local mirror, or wire up a complex network mirror configuration just to try out a two-line fix. None of those options belong in a tight edit-compile-test loop.

The dev_overrides block in the Terraform CLI configuration file solves this. It tells Terraform to skip the registry entirely for a named provider and load the binary from a local path instead. On macOS and Linux, this file is ~/.terraformrc. On Windows, it is %APPDATA%\terraform.rc.

Rebase. Squash. Merge. Repeat.

You open a pull request. The CI checks pass. A reviewer leaves a comment:

"Please squash your commits and rebase onto the latest main."

If you are new to contributing to open source or working on a team with a structured workflow, that request can feel like an obstacle between you and getting your work merged. It is not. It is a signal that the project cares about its history, and that caring about history is worth your time too.

This post covers the contributor side: what to do to a branch before opening a pull request (or merge request, as GitLab calls it), covering rebase, squash, and sign.

The maintainer side, covering the three GitHub merge strategies and why squash and merge is the right default, is covered in Squash and Merge: A Better Default.

A lot of what follows is inspired by Marc Gasch's Git rebase, squash...oh my!. This post builds on that foundation and connects these practices to the structured commit workflow covered in Conventional Commits: How to Write a Better Git Commit Message and the contributor expectations described in CONTRIBUTING.md: Writing Practical Contribution Guidelines for GitHub Repositories.