How to operate Renovate

This guide covers the recurring operational tasks for the Renovate bot. All commands target the kup6s cluster; set your context with --context kup6s.

Trigger a manual run

The bot runs nightly, but you can trigger it on demand. Use cronjob/renovate for the kup6s/dp repositories or cronjob/renovate-helix for the heidi repositories:

kubectl --context kup6s -n renovate create job renovate-manual --from=cronjob/renovate
kubectl --context kup6s -n renovate wait --for=condition=complete --for=condition=failed job/renovate-manual --timeout=600s
kubectl --context kup6s -n renovate logs job/renovate-manual

Delete the manual job when you are done, so the name is free for the next run:

kubectl --context kup6s -n renovate delete job renovate-manual

Force a rate-limited update

When a repository already has prConcurrentLimit open merge requests, further updates wait under Rate-Limited in that repository’s Dependency Dashboard issue.

To release one now, open the Dependency Dashboard issue and select the checkbox next to the update. Renovate creates the merge request on its next run.

To raise the cap instead, edit prConcurrentLimit in the repository’s renovate.json.

Rotate a group access token

Each instance authenticates with its own GitLab group access token, and every token expires yearly. Rotate a token before expiry:

  1. In GitLab, open the instance’s group — kup6s/dp for key gitlab-token, heidi for key gitlab-token-heidi — and select Settings ‣ Access Tokens.

  2. Create a token named renovate-bot with the Developer role and the api scope.

  3. Patch the source secret’s key with the new value. The secret holds several keys, so patch — do not recreate it:

    kubectl --context kup6s -n application-secrets patch secret renovate-secrets-source \
  --type merge -p '{"stringData":{"gitlab-token":"NEW_TOKEN"}}'

  4. ESO refreshes renovate-secrets within its refresh interval; the next run uses the new token.

  5. Revoke the old token in GitLab.

Investigate a failed build

A merge request that changes only config.yaml, with no manifests/ diff, means the postUpgradeTasks build failed.

  1. Read the run logs and look for artifactErrors:

    kubectl --context kup6s -n renovate logs job/renovate-manual | grep -A3 artifactErrors

  2. Reproduce the exact command in the Renovate image against a fresh clone:

    kubectl --context kup6s -n renovate run repro --rm -i --restart=Never \
  --image=renovate/renovate:43.263.9-full --command -- bash -lc '
  cd /tmp && git clone -q https://oauth2:TOKEN@git.bluedynamics.eu/kup6s/dp/dp-infra.git
  cd /tmp/dp-infra && sh -c "cd myapp && npm ci && npm run build"'

Common causes are a missing committed imports/ directory, a missing cdk8s-cli dependency, or a command that does not match allowedCommands. Refer to Renovate configuration reference for the build prerequisites.

Note

A build that fails because a major version genuinely breaks the code is expected behavior, not a bot fault. Do not merge such an update; the failed build is the signal to hold it.

Respond to the staleness alert

RenovateRunStale fires per CronJob when it has not succeeded for more than 36 hours; the cronjob label names the affected instance.

Check the recent jobs and the last run’s logs:

kubectl --context kup6s -n renovate get jobs
kubectl --context kup6s -n renovate logs job/<most-recent-job>

A stale run usually means an expired token, a GitLab outage, or a repository-wide config error.