Skip to main content
Every version a Kanso Labs repository pins exactly is moved forward by Renovate, through one self-hosted runner in kanso-labs/renovate. There is no Renovate app installation and no per-repository bot: one scheduled workflow runs Renovate against every repository it lists.

​
How it runs

The Renovate workflow runs every three hours. It mints a short-lived token for the organization’s GitHub App, then runs Renovate against each managed repository. The branches and pull requests it opens land in those repositories, not in the runner’s. Because Renovate authenticates as an app, its commits are made through GitHub’s API: they arrive signed, and show as Verified under kanso-labs[bot].

​
What every repository gets

The settings that have to hold everywhere live in one shared preset, renovate-config.json in kanso-labs/.github, referenced as local>kanso-labs/.github:renovate-config.

​
Configuring a repository

Renovate reads configuration from three places, and a repository’s own file overrides the other two: A repository’s own file replaces list-valued settings rather than adding to them, extends above all. So it restates both presets, in this order, since a later preset wins:
Put what only that repository wants beside them: a package group, a version ceiling with the reason it exists, or a narrower rule that holds one package back from automerging. A rule there lands after the preset’s, so it wins.
A setting meant for every repository goes in the shared preset, never in config.js. Every repository with a config of its own extends config:recommended, which reinstates whatever config.js turned off.

​
Adding a repository

Listing a repository in the repositories array of the runner’s config.js is the whole opt-in. Onboarding is off and no config file is required, so a repository receives no onboarding pull request.
Remove a repository from that list in the same change that deletes or renames it on GitHub. Renovate fails the whole run on a name it cannot resolve, which stops updates in every other repository too.
A repository that calls the shared actions has to be listed, since Renovate is the only thing that bumps those exact tags. And none should carry a .github/dependabot.yml for version updates: the two bots would open competing pull requests for the same upgrades. Dependabot is left to open security fixes alone.

​
Asking Renovate to act now

Renovate reads a ticked rebase checkbox only on its next run, up to three hours away. A repository that calls the shared _renovate-command.yaml workflow can comment @renovate rebase on a Renovate pull request instead, which ticks the box and starts a run within a minute. Anyone with access to the runner can also start a run by hand, with a dry run that logs what would change without writing anything: