I push a feature branch a dozen times a week. Every single time, the dance is the same: git push, switch to the browser, click the “Create MR” button, set assignee, set reviewer, add labels, wait for CI, click merge, switch back to terminal, git checkout main, git pull, git branch -d feature/.... It’s not hard. It’s just tedious — and the kind of friction that adds up over a week.

I had a shell script glued together with glab, gh, jq, yq, and gum doing this for years. It worked, but it broke whenever any of those tools updated and was a pain to ship to a fresh laptop. So I rewrote the whole thing in Go and called it auto-mr. One binary, no external CLIs, works on both GitLab and GitHub.

I spend a lot of time in Claude Code, and a lot of time in GitLab. The constant tab-switching between the two — copy an issue ID, paste it into a prompt, jump back to read a job log, paste that too — got tiresome. So I wrote gitlab-mcp, a Model Context Protocol server that lets Claude Code talk to GitLab directly.

GitLab access tokens expire. Project tokens, group tokens, personal access tokens — all of them. The trouble is that the expiration dates live in different corners of the UI, and you usually find out one expired the morning a CI pipeline mysteriously starts failing.

gitlab-token-expiration is the small tool I wrote to never have that morning again.

gitlab-backup2s3: Encrypted GitLab Backups to S3, with Kubernetes Support

Source code: github.com/sgaunet/gitlab-backup2s3 Helm chart: github.com/sgaunet/helm-gitlab-backup2s3

In the previous article, I covered gitlab-backup, a CLI tool for exporting GitLab projects and groups as portable archives. It handles the export, the restore, and supports both local and S3 storage natively.

But for production backup workflows — especially in a Kubernetes environment — you often want more: scheduled execution, optional encryption at rest, and a container image that bundles everything together. That’s exactly what gitlab-backup2s3 brings to the table.

When your Go project depends on an internal library living in a private GitLab repository, a plain go get will fail — GitLab doesn’t know who is asking, and Go doesn’t know the repository is private. Fortunately, a handful of configuration steps sorts everything out, both locally and in CI.