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, one ConfigMap and CronJob per instance, and a PrometheusRule.

Key in config.yaml	Example	Notes
app.imageTag	44.59.2-full	Renovate image tag; the -full variant ships Node, helm, and package managers
gitlab.endpoint	https://git.bluedynamics.eu/api/v4	GitLab API base
instances[].nameSuffix	"", -helix	Resource-name suffix; the empty suffix is the original kup6s instance
instances[].schedule	23 1 * * *	Cron schedule, evaluated in Europe/Vienna
instances[].tokenSecretKey	gitlab-token-heidi	Key in renovate-secrets holding the instance’s GitLab token
instances[].repositories	list	Repositories the instance operates on

Each instance is one GitLab group: a Renovate run authenticates with exactly one platform token, and group access tokens are bound to their group.

Every 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 per instance (a bot user with api scope and Developer role on the instance’s group).

The tokens live in the application-secrets namespace as renovate-secrets-source and are mirrored into the renovate namespace by ESO as renovate-secrets.

gitlab-token

Required. The group access token for kup6s/dp. Exposed to the renovate CronJob as RENOVATE_TOKEN.

gitlab-token-heidi

Required. The group access token for heidi. Exposed to the renovate-helix CronJob as RENOVATE_TOKEN.

github-token

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

Important

The group access tokens expire yearly. Rotate them before expiry — see How to operate Renovate.

Global config (config.js)

One ConfigMap per instance (renovate-config, renovate-config-helix) 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.

• strimzi and pages (helix-infra-charts) vendor their operator CRDs, because Helm never upgrades a chart’s crds/ directory. Their rules run the component’s scripts/update-crds.sh before the build; pages additionally runs npm run import, because its cdk8s.yaml references the versioned CRD file.

helix repositories

helix-infra-charts follows the same layout as dp-infra: one CDK8S component per directory, pinned versions annotated in config.yaml. Its renovate.json excludes monitoring/** (helix-stage, GitOps-frozen) and staging-secrets/** through ignorePaths.

helix-argocd contains no version pins — its ArgoCD applications point at helix-infra-charts paths without revisions. Renovate manages only the npm toolchain there and targets the deployed production branch through baseBranches; the config lives on the default branch main and identically on production.

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.