The Kubernetes CronJob runs in renovate every six hours with overlapping CronJob executions forbidden. Prepare the bot PAT from the Secret example. Give the dedicated Gitea user access to the repositories it should update.

renovate.json is the source configuration. The ConfigMap is a generated copy:

.gitea/workflows/sync-renovate-configmap.sh
.gitea/workflows/sync-renovate-configmap.sh --check

Run those commands from the repository root. The renovate-ci workflow checks that the generated configuration agrees with the source.

Run manually

From the repository root:

kubectl create job --from=cronjob/renovate renovate-manual-$(date +%s) -n renovate
kubectl get jobs,pods -n renovate

Alternatively use the renovate-run Actions workflow. It reads the image tag from the CronJob and accepts repository, log-level, and dry-run inputs. Actions requires RENOVATE_TOKEN; RENOVATE_GITHUB_COM_TOKEN is optional. The Actions concurrency group and the CronJob policy are separate, so avoid starting both against the same repository at once.

For Compose, copy .env.example to .env in this directory and run docker compose -f renovate-compose.yaml run --rm renovate. That file is a manual entry point and is not selected by the deploy workflow.

The config also tracks chart versions in deploy-lib.sh and tool versions in tool-versions.env. Renovate opens pull requests; the normal CI and deploy workflows handle changes after merge.

Inspect

From the repository root:

kubectl get pods,svc,pvc -n renovate
kubectl get events -n renovate --sort-by=.metadata.creationTimestamp

See the repository README for deployment selection.