Skip to content

Dependency Automation

BoardReadyOps uses Renovate as the single source of truth for routine version-update pull requests.

Execution

  • .github/workflows/renovate.yml validates renovate.json on pull requests and changes to main. Validation runs the official Renovate image by immutable tagged digest, with the repository mounted read-only and container networking disabled, so validation cannot drift through dynamically resolved pnpm dlx transitives.
  • The workflow renovate-version input is the self-hosted runtime version source of truth. A custom.regex manager tracks the validator image tag and digest, and both self-hosted Renovate dependencies are grouped into a manual-review exception PR instead of entering the automatic path.
  • The pinned Renovate runner executes at 06:17 Europe/Istanbul on weekdays and can also be started manually.
  • The runner is explicitly scoped to oaslananka/boardreadyops; repository autodiscovery and onboarding are disabled.
  • The workflow uses the GH_AUTH_TOKEN repository secret. That credential must belong to a dedicated automation identity with the minimum repository permissions required to create branches, pull requests, labels, and issues.
  • Post-upgrade command execution is restricted through RENOVATE_ALLOWED_COMMANDS to the exact corepack pnpm run renovate:post-upgrade entry point. That repository-controlled script creates an isolated temporary pnpm store for the dependency install, native rebuild, NOTICE refresh, and committed dist/ rebuild, then removes the store. This prevents shared-runner pnpm store metadata from breaking pnpm licenses list while keeping Renovate unable to execute arbitrary post-upgrade commands.
  • Renovate itself never runs on a pull-request event, so untrusted pull-request code cannot obtain the automation token.

Policy layers

renovate.json is self-contained. It directly carries the conservative baseline that BoardReadyOps previously inherited from github>oaslananka/.github:renovate-config: the Europe/Istanbul timezone, seven-day routine release quarantine, strict internal age filtering, two new PRs per hour, five concurrent PRs, digest pinning, weekly lockfile maintenance, semantic commits, Dependency Dashboard, and explicit approval for major upgrades.

This local fallback became authoritative after the scheduled run on October 2, 2026 failed to resolve the shared preset. Keeping the baseline in the repository prevents dependency maintenance from depending on a second repository or on broader token scope. BoardReadyOps-specific schedule, managed package managers, generated NOTICE/dist/ refresh, protected package groups, vulnerability-PR policy, and merge routing remain local as before. Generated output, dependency trees, and test fixtures remain excluded from discovery.

Automatic path

Low-risk development dependency and @types/* non-major updates remain the routine path. Same-version GitHub Action digest refreshes are also routine when they do not touch security, release, provenance, publication, container-release, or binary-release workflows.

Routine classification never bypasses GitHub Rulesets. Required checks must pass and review conversations must be resolved before an explicit maintainer squash merge. The automerge label on low-risk dependency groups is classification metadata only; BoardReadyOps does not enable Renovate's own automerge: true path and Mergify does not queue or merge these pull requests.

Exception path

Major updates, TypeScript, core runtime/GitHub integration dependencies, self-hosted Renovate runtime/validator upgrades, vulnerability-remediation PRs, non-digest GitHub Action updates, Actions changes in protected workflows, and Dockerfile/Docker Compose updates carry manual-review and remain on hold until a maintainer clears the exception.

GitHub Actions and container references remain digest-pinned. Security vulnerability remediation bypasses the routine schedule and release-age wait, requests the lowest known-safe version, and remains manual-review only.

Pull-request creation

Routine minimum-age waiting is enforced by Renovate's strict internal checks before branch creation. BoardReadyOps CI begins on pull_request, not on bare Renovate branches, so the repository does not use prCreation: not-pending; otherwise a dependency branch can wait for checks that cannot start until the pull request exists.

Files

  • renovate.json controls project-specific Renovate behavior.
  • .github/workflows/renovate.yml validates and runs the pinned self-hosted Renovate release.
  • .mergify.yml provides pull-request classification plus a manual-only main merge queue; the GitHub main ruleset remains the merge authority.
  • tests/unit/scripts/security-automation-config.test.ts prevents accidental weakening of the automation contract.
  • Version-update PR configuration must not be duplicated in another dependency updater.

Last verification

  • On October 4, 2026, Mergify was configured as a manual-only queue: there is no auto-merge/auto-queue condition, and a maintainer must explicitly enqueue a PR with @mergifyio queue main. GitHub Rulesets remain authoritative for merge eligibility and required checks.
  • On July 20, 2026, Renovate 43.272.4 completed a full dry-run under Node.js 24.18.0.
  • The repository reported activated, enabled, and onboarded, and Renovate discovered 269 dependencies across npm, GitHub Actions, Dockerfiles, and Docker Compose.
  • After the workflow reached main, manual workflow run 29767533207 completed both renovate / validate and renovate / run successfully.
  • The authenticated run created Dependency Dashboard issue #196 and populated pending-approval, awaiting-schedule, status-check, abandoned-dependency, and detected-dependency sections.
  • No update branches or pull requests were created outside the configured schedule or approval policy.
  • On September 17, 2026, the shared oaslananka/.github preset was verified at commit c44946c82eeb6c5041dbc94f371c55015679cbe0 (renovate-config.json blob 6ad5d7c7232908a686a4b9e0404fb30f4d30c2da).
  • On October 2, 2026, scheduled run 36992286708 failed before repository processing because that shared preset could no longer be resolved. BoardReadyOps therefore activated the documented repository-local recovery path instead of widening GH_AUTH_TOKEN access to another repository.
  • BoardReadyOps implementation PR #819 merged through Mergify's default queue after the main Ruleset conditions, including ci / risk-profile and security / gate, were satisfied.
  • Post-merge manual Renovate workflow run 35251461740 ran against merge commit 6e5a7b020a335a19b57ec251969d4dd8f84efa20; both renovate / validate and renovate / run completed successfully.
  • Dependency Dashboard #196 updated at 2026-09-17T17:16:35Z. No Renovate or Dependabot PR remained open after the run; routine developer-tooling, type-definition, and lockfile updates were awaiting their schedule while major updates remained pending approval.
  • No representative low-risk dependency PR auto-entered Mergify during this verification because the run created no PR outside the configured schedule. The next naturally eligible low-risk Renovate PR remains the live queue/merge acceptance sample.

Operations

  1. Confirm the repository-local conservative baseline remains present in renovate.json; do not reintroduce an external preset dependency without a separately verified availability and credential contract.
  2. Run corepack pnpm run renovate:validate after policy changes.
  3. Confirm security-automation-config.test.ts and mergify-integration.test.ts pass.
  4. Confirm manual-review is present on protected updates and absent from an eligible low-risk update.
  5. Confirm the PR receives the repository's required Ruleset checks and that review conversations are resolved.
  6. After the PR is intentionally approved for merge, enqueue it with @mergifyio queue main (or the Mergify queue control). Do not enable Mergify auto-merge/auto-queue; an open green PR should remain open until a maintainer explicitly queues it.
  7. Run the Renovate workflow manually after first installation or credential rotation and confirm the Dependency Dashboard can be updated.
  8. Rotate GH_AUTH_TOKEN immediately if its owner or permissions change unexpectedly.