renovate

Shared Renovate configuration preset for all cdamian Codeberg repos. The self-hosted bot itself runs on signal (see the renovate role in the servers monorepo); this repo holds only the policy.

How repos consume it

The bot's onboardingConfig seeds every repo's onboarding PR with:

{ "extends": ["local>cdamian/renovate"] }

local>cdamian/renovate resolves to default.json in this repo's default branch. Change the policy here once and the next scheduled run picks it up across every repo — no per-repo edits. This is the Renovate analogue of the shared/roles/ directory in servers.

What default.json does

• config:recommended as the base, semantic commits disabled — commit messages stay in the plain Update dependency x to y style, matching the repos' non-conventional history rather than chore(deps):.
• rangeStrategy: bump — the repos pin Python deps by lower bound only (requests>=2.32). The default replace strategy would never open a PR for those (a new release still satisfies >=), so bump is used to raise the floor on each release — mirroring the manual lower-bound CVE bumps in the history. This is the main tunable: switch to replace if it's too chatty.
• Minor + digest grouped into one routine PR. Patch updates are disabled in the routine flow (too noisy) and majors are disabled — but a patch or major that fixes a vulnerability still raises its own PR via the OSV path, which overrides packageRules. So security fixes always come through; routine churn is limited to minors.
• Custom manager for Ansible image pins — Quadlet image tags live as <name>_image: registry/path:tag variables in roles/*/defaults/main.yml and group_vars/*, which no built-in manager detects. The regex manager matches them with a docker datasource. It deliberately skips Jinja-templated tags (:{{ var }}) and tagless images.
• Own images disabled — codeberg.org/cdamian/* are :latest CI builds, not upstream-versioned, so there's nothing to bump.
• Lock files kept fresh — rebaseWhen: behind-base-branch rebases an open PR whenever its base moves ahead, so its lock file (e.g. uv.lock) gets re-resolved before merge. The default only rebases on conflict, which let PRs opened before a repo gained uv.lock merge with a stale lock and break uv sync --locked in CI. lockFileMaintenance (weekly, Mon 06:00 to land inside the bot's 06:00/18:00 timer window) is the periodic safety net for any drift the per-PR path misses.

No GitHub

fetchChangeLogs: "off" disables release-note retrieval. Renovate would otherwise hit github.com to pull changelogs for upstream packages (whose sourceUrls point at GitHub), warning on every package because the bot has no GITHUB_COM_TOKEN — and we keep none, by design. PRs just omit the release-note section; the version diff and the dependency dashboard are unaffected.

Changelogs are not the only github.com consumer, though: when a manager has to regenerate a lockfile (e.g. uv.lock), stock Renovate resolves the python/uv toolchain through containerbase, which queries github.com release datasources — rate-limited without a token, so uv lock fails and the PR ships a stale lock. That path can't be turned off here; it's solved at the bot level (the renovate role runs a custom image with python3 + uv baked in and RENOVATE_BINARY_SOURCE=global), so lockfile regeneration never installs a toolchain from github.com.

With the toolchain bundled and fetchChangeLogs: "off", runs make no successful github.com call — api.github.com traffic is zero in the logs.

One cosmetic artefact remains: the pep621 manager synthesises a python dependency from requires-python whose datasource is github.com (CPython releases). The bot can't reach it without a token (we keep none), so it resolves to no-result and logs a benign Failed to look up python-version package python WARN — no network call succeeds, nothing breaks. The matchPackageNames: ["python"] rule disables it as an update (we bump requires-python by hand), but note that enabled: false does not silence the lookup WARN itself — Renovate emits it during the lookup phase regardless of packageRules. It's log noise on the repos that fully re-extract each run, not github traffic.

Cadence

There is no schedule in the config on purpose. The systemd timer on signal (renovate.timer, twice daily) is the single source of cadence — adding an internal schedule on top would just create a confusing second gate.

Testing a change

Renovate validates config on every run, but to check locally before pushing:

podman run --rm -v "$PWD/default.json:/tmp/default.json:Z" \
  docker.io/renovate/renovate:43 renovate-config-validator /tmp/default.json

After pushing, watch the next run on signal:

ssh signal 'sudo systemctl start renovate.service && journalctl -u renovate.service -f'