Skip to content

feat: reusable Renovate workflow for org-wide self-hosted runs#3

Merged
bigpuritz merged 1 commit into
mainfrom
feat/reusable-renovate
May 9, 2026
Merged

feat: reusable Renovate workflow for org-wide self-hosted runs#3
bigpuritz merged 1 commit into
mainfrom
feat/reusable-renovate

Conversation

@bigpuritz
Copy link
Copy Markdown
Contributor

Summary

Adds .github/workflows/renovate.yml as a reusable workflow so every plugwerk repo can trigger self-hosted Renovate through a single source of truth instead of copying the 70-line trigger into each repo.

Pulls in scope what was originally DEFER in plugwerk/plugwerk#398 — turns out the concrete need showed up immediately: when adopting org-wide Renovate config in examples and website, those repos have the same Mend-Hosted opacity issue that triggered the original self-hosted setup in plugwerk/plugwerk (#462). Three copies of the same workflow is the wrong answer; a reusable workflow plus 15-line stubs is the right one.

Design

  • on: workflow_call with two optional inputs:
    • logLevel (default info) — passes through to RENOVATE_LOG_LEVEL
    • configurationFile (default .github/renovate.json) — for callers that keep their config elsewhere
  • concurrency keyed on ${{ github.repository }}-${{ github.ref }} so runs against the same repo serialize but different repos run in parallel.
  • SHA-pinned actions (actions/checkout@v6, renovatebot/github-action@v46.1.13) — same pins as the existing plugwerk/plugwerk/.github/workflows/renovate.yml.
  • permissions are not declared in the reusable workflow — callers declare them on the job that uses this workflow, which is the GitHub-recommended pattern.

Token model

Single-repo. The reusable workflow uses ${{ secrets.GITHUB_TOKEN }}, which in a workflow_call resolves to the caller's GITHUB_TOKEN, scoped to the caller's repo. No PAT, no GitHub App, no cross-repo write access. Adopting this workflow has the same security posture as the existing per-repo trigger.

Consumer stub

Three follow-up PRs (in plugwerk/plugwerk, plugwerk/examples, plugwerk/website) add this stub to each repo's .github/workflows/renovate.yml:

name: Renovate

on:
  schedule:
    - cron: "0 4 * * 1-5"
  workflow_dispatch:
    inputs:
      logLevel:
        description: "Log level"
        type: choice
        default: info
        options: [info, debug]

jobs:
  renovate:
    uses: plugwerk/.github/.github/workflows/renovate.yml@main
    permissions:
      contents: write
      pull-requests: write
      issues: write
    with:
      logLevel: ${{ inputs.logLevel || 'info' }}

In plugwerk/plugwerk the stub replaces the existing 76-line workflow; in examples and website it is brand new.

What this PR does NOT do

  • Does not migrate to a multi-repo GitHub App or PAT — token model stays single-repo.
  • Does not change the schedule, concurrency strategy, or action versions; only the location of the canonical workflow.
  • Does not affect Mend-Hosted Renovate; that runs in parallel.

Verification after merge

  1. The three follow-up PRs in plugwerk/plugwerk, plugwerk/examples, plugwerk/website can then be opened and merged in any order.
  2. After each follow-up merge: trigger the workflow manually via gh workflow run renovate.yml --repo <repo> and confirm the run appears in the Actions tab with the same log shape as the original.
  3. The reusable workflow itself does not run — it has no push/pull_request triggers — so there is no PR check to wait on here.

Type of Change

  • CI/Build

AI Agent Disclosure

  • This PR was authored by an AI agent (Claude Opus 4.7)

Adds .github/workflows/renovate.yml as a reusable workflow (on:
workflow_call) so every plugwerk repo can run self-hosted Renovate
through a single place instead of duplicating the 70-line trigger.

Inputs:
- logLevel (default 'info'): pass-through to RENOVATE_LOG_LEVEL
- configurationFile (default '.github/renovate.json'): per-caller
  override if a repo keeps its config elsewhere

Token model is single-repo: each caller's GITHUB_TOKEN is scoped to
its own repo. The reusable workflow does not add cross-repo write
access, so adopting it is no different in security posture from the
original per-repo trigger.

Concurrency keys on github.repository so two runs against the same
repo serialize but different repos run in parallel.

README updated with the consumer-stub example and override behavior
note.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant