Renovate Batch Update

/renovate-batch-update — Consolidated Dependency Update

Turns the weekly pile of individual Renovate PRs on grafana/quickpizza into tested PRs, instead of reviewing/merging each one by hand.

Boundary: this skill opens draft PRs to main. It never merges to main itself — that's a shared-branch action and stays a human call.

Produces two separate PRs, not one: a code/dependency batch (Go modules, npm packages, Docker base image tags, security patches) and, only if any exist, a GitHub Actions batch. This is a hard split, not optional risk-tiering — see "Why GitHub Actions bumps get their own PR" below.

Step 0: Sanity check

• Confirm the working tree is clean (git status). If not, stop and tell the user — don't stash or discard their work.
• Confirm the current branch, then git fetch origin --prune.
• Check whether port 3333 is already in use (lsof -i :3333). Quickpizza's port is hardcoded in cmd/main.go with no override, and a long-running local Docker container (docker ps --filter publish=3333) commonly holds it. If so, ask the user before touching it. If they agree, docker stop <name> before Step 4 and docker start <name> again once k6 finishes, pass or fail.

Why GitHub Actions bumps get their own PR

A GitHub Actions version bump changes the CI workflow itself — the thing meant to validate the batch. This skill's local testing (make build + make test-go + k6) can't exercise workflow-level behavior at all; only that PR's own CI run can.

1. Never mix Actions bumps into the code/dependency batch. A CI-breaking Actions change and a real code regression both just show up as "CI failed" if they're in the same batch — keep Actions bumps in a PR that contains only Actions bumps, so a failure there is unambiguous.
2. The acceptance bar for the Actions batch is its own CI run, not a local check. Push it and read its checks. A first-push failure is expected and is the batch doing its job — report it plainly in the PR body rather than fixing it silently. The fix itself (e.g. pinning a version in ci.yaml) is a main-level CI change, out of scope for a dependency-bump PR.

This holds regardless of which Actions bump happens to break something — the reason is structural (only a workflow's own run can validate a change to that workflow), not tied to any specific action.

Step 1: Collect open Renovate PRs

gh pr list --state open --json number,title,headRefName,labels \
  --search "head:renovate/ OR head:security-" --limit 100

Renovate branches are prefixed renovate/; security branches use the additionalBranchPrefix: "security-" from renovate.json, so also match security-* heads. From each PR's labels, note: update-major / update-minor / update-patch, and any severity:* / automerge-security-update.

Don't request mergeable from gh pr list — GitHub computes it lazily and it's UNKNOWN for most PRs right after a fetch. Step 2's actual git merge is the only reliable mergeability check.

Dedupe overlapping PRs before merging, not by discovering conflicts. renovate.json groups npm/go/docker updates into one PR (e.g. renovate/npm-dependencies), but Renovate also opens narrower individual security-* PRs for the same packages. If a grouped PR and a security PR touch the same package (compare titles), merge the grouped one and skip the narrower one — it's superseded, and merging both guarantees a conflict.

Exclude the observability-stack container images group entirely. These are the Grafana observability stack images (Alloy, LGTM, etc.) upgraded manually while deciding whether to adopt new stack features — batching them defeats that review. Read renovate.json's packageRules, find the rule matching matchManagers: ["docker-compose", "terraform"], and take its groupName. Exclude any PR whose title contains that groupName, including its (major) variant. Don't merge these, risk-assess them, or mention them in the batch PR body — they're out of scope for this skill, not a drop. Tell the user how many were left untouched by design.

Split off GitHub Actions bumps into their own batch — filter by the github-actions label (applied via presets/github-actions in renovate.json's extends), not by branch name or title. Steps 2-6 below run twice: once for the code/dependency PRs, once for the Actions PRs, each on its own branch and its own PR. Within the Actions set, dedupe the same way as above — e.g. a digest-only pin and a major-version bump for the same action will conflict; keep the lower-risk one.

Step 2: Build the batch branch(es)

# Code/dependency batch:
git checkout -b renovate-batch/$(date +%Y-%m-%d) origin/main
# GitHub Actions batch, if any Actions PRs exist:
git checkout -b renovate-actions-batch/$(date +%Y-%m-%d) origin/main

Merge order within the code/dependency batch: lowest-risk first (security-patch, security-minor), then grouped patch/minor PRs, then majors last (majors are the first candidates to drop if later steps fail).

git merge --no-ff origin/<headRefName> -m "merge: <PR title> (#<number>)"

On a clean merge, continue. On a conflict, git merge --abort, record <PR> — dropped: merge conflict, and continue to the next PR. Don't attempt manual conflict resolution.

Why conflicts are common here: this repo vendors Go dependencies (vendor/), so any single-module bump touches go.mod, go.sum, and often unrelated files under vendor/ (shared semconv/version directories get rewritten wholesale). Once one otel/grpc/x-net-family bump is merged, every other PR touching a related module will conflict with it, even though the version bumps are logically compatible. Treat these as expected noise in the batch PR summary, not as unsafe changes that got rejected.

Step 3: Risk-assess only what survived Step 2

Risk-assessing before merging wastes effort on PRs that just get dropped as conflicts. Assess only the PRs that are actually in each batch branch.

For the code/dependency batch, route by ecosystem:

• Go/npm code libraries: grafana-engineering:dependency-bump-context
• Docker/container image tags (e.g. the Dockerfile base image group): grafana-engineering:analyze-image-dep-bump-pr

For the GitHub Actions batch, no skill covers this — read each action's actual release notes between the current and target version (gh release view <version> -R <owner>/<repo>), looking specifically for breaking changes to the action's runtime behavior, not just its own dependency bumps. Version number alone doesn't reveal this kind of change, and skipping the check is how a CI-breaking bump gets through unnoticed.

Build a table — PR #, title, ecosystem, update type, severity, risk verdict — and keep it; it becomes the batch PR body.