Renovate configuration reference

Renovate reads three kinds of configuration: the deployment manifests in dp-infra/renovate/, the global config.js, and a renovate.json in each managed repository.

Deployment

The CDK8S code in dp-infra/renovate/ renders namespace, ClusterSecretStore, ExternalSecret, ConfigMap, CronJob, and PrometheusRule.

Key in config.yaml	Example	Notes
app.imageTag	43.263.9-full	Renovate image tag; the -full variant ships Node, helm, and package managers
app.schedule	23 1 * * *	Cron schedule, evaluated in Europe/Vienna
gitlab.endpoint	https://git.bluedynamics.eu/api/v4	GitLab API base
gitlab.repositories	list	Repositories Renovate operates on

The CronJob uses concurrencyPolicy: Forbid and an emptyDir working volume, so each run starts from a clean checkout.

Secrets

Renovate authenticates as a GitLab group access token (a bot user on group kup6s/dp, api scope, Developer role).

The token lives in the application-secrets namespace as renovate-secrets-source and is mirrored into the renovate namespace by ESO as renovate-secrets.

gitlab-token

Required. The group access token. Exposed to the container as RENOVATE_TOKEN.

github-token

Optional. A GitHub read-only token. Exposed as GITHUB_COM_TOKEN for release-note retrieval. Without it, merge requests omit upstream changelogs.

Important

The group access token expires yearly. Rotate it before expiry — see How to operate Renovate.

Global config (config.js)

The ConfigMap renovate-config holds the admin-level configuration that must not live in a managed repository.

It sets platform, endpoint, the repositories list, onboarding: false, requireConfig: 'required', the git author, and allowedCommands.

allowedCommands is a security allowlist of regular expressions. A postUpgradeTasks command runs only if it matches one of them.

Warning

Renovate executes postUpgradeTasks commands without a shell. Wrap any command that uses cd or && in sh -c '...', and keep the allowedCommands regex in sync.

Per-repository config (renovate.json)

Each managed repository carries a renovate.json at its root. It sets assignees (drives the notification email), labels, prConcurrentLimit, the custom manager, and the package rules.

Comment-annotation manager

Pinned versions in a config.yaml are updated through a comment placed directly above the version line:

# renovate: datasource=docker depName=solidtime/solidtime
solidtime: "0.17.0"

# renovate: datasource=helm registryUrl=https://charts.openproject.org depName=openproject
chartVersion: "13.9.0"

The annotation fields are:

datasource

Required. docker or helm.

registryUrl

Optional. The chart repository URL for helm.

depName

Required. The image or chart name Renovate looks up upstream.

versioning

Optional. A non-default versioning scheme.

Only lines carrying a # renovate: comment are matched. An unannotated config.yaml produces no custom-manager updates.

Package rules and manifest regeneration

A CDK8S deployment must regenerate its committed manifests when a version changes. One generic package rule per repository does this for every deployment, using Renovate’s {{{packageFileDir}}} template and executionMode: update so the build runs in the directory of whichever package file changed:

{
  "matchFileNames": ["**"],
  "postUpgradeTasks": {
    "commands": ["sh -c 'cd {{{packageFileDir}}} && (test -f pnpm-lock.yaml && pnpm install --frozen-lockfile || npm ci) && npm run build'"],
    "fileFilters": ["**/manifests/**", "**/package-lock.json", "**/pnpm-lock.yaml"],
    "executionMode": "update"
  }
}

The command auto-detects the package manager: pnpm install --frozen-lockfile when a pnpm-lock.yaml is present, otherwise npm ci.

Important

The allowedCommands regex must match this command literally. Renovate compiles the allowlist entries as regular expressions, so the shell metacharacters (, ), and || are matched with . rather than backslash-escaped — escaping does not survive the ConfigMap → config.js → RegExp chain.

Deployments that need a specific rule

A more-specific rule after the generic one overrides it for these paths:

• nextcloud is an npm workspace; a deployment-level cd cannot build it. Its rule builds from the workspace root (cd internal/nextcloud && npm ci && npm run build).

• mailu and nextcloud currently set postUpgradeTasks: {"commands": []} (disabled). mailu depends on the unpublished cdk8s-mailu through a workspace:* link to generic-charts/, which a dp-infra-only checkout cannot resolve; nextcloud carries pre-existing manifest drift that must be reviewed before its first regenerated merge request. Their merge requests are review-only until these are resolved — rebuild manually in the meta-repo workspace before merging.

Build prerequisites for a managed deployment

The postUpgradeTasks build runs in a clean container checkout, so the deployment must build hermetically:

• Commit the generated imports/ directory. Most deployments gitignore it; a managed deployment must track it, or tsc fails on the missing types.

• Declare cdk8s-cli as a dependency. Without it, cdk8s synth fails with cdk8s: not found under npm ci.

• Commit the lockfile (package-lock.json or pnpm-lock.yaml).

Rate limiting

prConcurrentLimit caps the number of open merge requests per repository. Updates beyond the cap are listed under Rate-Limited in the repository’s Dependency Dashboard issue and are created as slots free up.