ci: manage dev-kit's own dependencies with Renovate

.github/workflows/renovate-auto-approve-self.yml

@@ -0,0 +1,29 @@
+name: renovate-auto-approve
+
+# dev-kit calling its own reusable workflow, the way a consumer calls it. The
+# reference is local rather than `opendefensecloud/dev-kit/...@<sha>`: a
+# same-repo reusable workflow can be addressed by path, which keeps this honest
+# — it always exercises the version in the branch — and avoids a self-reference
+# that would need a release's own SHA before that commit exists.
+#
+# The label triggers are not optional. Renovate adds the automerge label, often
+# after opening the PR, and the workflow revokes its approval when a PR gains
+# the block label or loses the automerge one. Without `labeled`/`unlabeled` the
+# stub silently never fires for either.
+on:
+  pull_request:
+    types: [opened, reopened, synchronize, labeled, unlabeled]
+
+permissions:
+  contents: read
+
+jobs:
+  approve:
+    uses: ./.github/workflows/renovate-auto-approve.yml
+    permissions:
+      # Both are needed, and a job-level block replaces the workflow-level one
+      # rather than adding to it. A called workflow cannot elevate what the
+      # caller grants, so omitting contents here leaves the repository activity
+      # API — the pusher check, and the revoke path — without access.
+      contents: read
+      pull-requests: write

.github/workflows/renovate-auto-approve.yml

@@ -1,14 +1,27 @@
 name: renovate-auto-approve
 
-# Reusable workflow. A consuming repo triggers it on pull_request and calls it:
+# Reusable workflow. A consuming repo calls it like this — the label triggers are
+# not optional, since Renovate usually adds the automerge label after opening the
+# PR, and the revoke path reacts to labels changing:
 #
+#   on:
+#     pull_request:
+#       types: [opened, reopened, synchronize, labeled, unlabeled]
+#   permissions:
+#     contents: read
 #   jobs:
 #     approve:
 #       uses: opendefensecloud/dev-kit/.github/workflows/renovate-auto-approve.yml@<sha-or-tag>
 #       permissions:
 #         contents: read
 #         pull-requests: write
 #
+# Both permissions belong on the job, not only at the workflow level: a
+# job-level block replaces the workflow-level one rather than adding to it, and
+# a called workflow cannot elevate what its caller grants. Omitting contents
+# there leaves the repository activity API — the pusher check, and the revoke
+# path — without access.
+#
 # It approves a Renovate PR that carries the automerge label, added by Renovate,
 # and not the block label (security), and only while the branch still holds
 # exactly one commit, authored by Renovate and signed, and pushed by Renovate.

README.md

@@ -276,15 +276,15 @@ keeps one small stub per workflow, which sets the triggers and the permissions
 and calls dev-kit. Pin each stub to a SHA like any other action; Renovate bumps
 them together with `DEV_KIT_VERSION`.
 
-| Workflow                    | Stub triggers                                          | Needs                           |
-| --------------------------- | ------------------------------------------------------ | ------------------------------- |
-| `update-action-pins.yml`    | `pull_request`                                         |                                 |
-| `conventional-commits.yml`  | `pull_request` (opened, edited, synchronize, reopened) | `.commitlintrc.yml` in the repo |
-| `osv-scanner.yml`           | `pull_request`, `push` to main, weekly                 | optional `scan-args` input      |
-| `issues-add-labels.yaml`    | `issues` (opened, reopened)                            |                                 |
-| `issues-add-to-project.yml` | `issues`, `pull_request` (opened)                      | `ADD_TO_PROJECT_PAT` secret     |
-| `renovate-auto-approve.yml` | `pull_request`                                         | see the header of the workflow  |
-| `renovate-dev-kit-lock.yml` | `pull_request` (opened, synchronize, reopened)         | `DEV_KIT_BOT_APP_*` org secrets |
+| Workflow                    | Stub triggers                                                      | Needs                           |
+| --------------------------- | ------------------------------------------------------------------ | ------------------------------- |
+| `update-action-pins.yml`    | `pull_request`                                                     |                                 |
+| `conventional-commits.yml`  | `pull_request` (opened, edited, synchronize, reopened)             | `.commitlintrc.yml` in the repo |
+| `osv-scanner.yml`           | `pull_request`, `push` to main, weekly                             | optional `scan-args` input      |
+| `issues-add-labels.yaml`    | `issues` (opened, reopened)                                        |                                 |
+| `issues-add-to-project.yml` | `issues`, `pull_request` (opened)                                  | `ADD_TO_PROJECT_PAT` secret     |
+| `renovate-auto-approve.yml` | `pull_request` (opened, reopened, synchronize, labeled, unlabeled) | see the header of the workflow  |
+| `renovate-dev-kit-lock.yml` | `pull_request` (opened, synchronize, reopened)                     | `DEV_KIT_BOT_APP_*` org secrets |
 
 No stub triggers on `merge_group`, as no repo uses a merge queue. A repo that
 turns one on must add the trigger to every stub whose check it requires, and

renovate.json

@@ -0,0 +1,6 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": [
+    "github>opendefensecloud/renovate-config"
+  ]
+}