Renovate¶
Deployment of Renovate¶
Renovate is an integrated package and can be deployed using the Big Bang Helm chart.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '18px', 'primaryColor': '#00758f', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#004d5c', 'lineColor': '#00758f'}, 'flowchart': {'curve': 'basis'}}}%%
flowchart LR
A(Renovate scans release tags) --> B(regexManager captures currentValue)
B --> C(Dependency Dashboard issue updates)
C --> D(Draft merge request opens)
linkStyle default stroke-width:3px
Example Deployment Values¶
packages:
renovate:
enabled: true
git:
repo: https://repo1.dso.mil/big-bang/product/packages/renovate.git
tag: 46.388.0-bb.0
values:
upstream:
cronjob:
schedule: '0 1 * * *'
renovate:
config: |
{
"platform": "gitlab",
"endpoint": "https://gitlab.example.com/api/v4",
"token": "your-gitlab-renovate-user-token",
"autodiscover": "false",
"dryRun": true,
"printConfig": true,
"repositories": ["username/repo", "orgname/repo"]
}
Config¶
The configuration sets up a self-hosted instance of Renovate that connects with a platform. In the example, we connect to GitLab using the GitLab API v4 at a specified URL.
Auth¶
It is recommended to use a repository-scoped auth token with developer access for least privilege.
Repositories¶
The repositories key in this self-hosted Renovate configuration specifies which repositories should be included in the update checks performed by Renovate. Accepts an array of strings or objects.
See Self Hosted Configuration for more details.
Cron Job¶
Refer to the Scheduling Renovate Guide.
Individual Package Configuration¶
The configuration file for Renovate is called renovate.json and is located in each project’s root directory. See Package Configuration.
Handling Scheduling in the Chart¶
packages.renovate.values.upstream.cronjob.schedule is copied into the
Kubernetes CronJob.spec.schedule. It requires Kubernetes-supported cron
syntax; prose such as every weekend is not valid there. The CronJob controls
when Renovate starts, not necessarily when it creates updates.
The default is 0 1 * * * (01:00 every day).
Renovate’s own repository schedule and schedule presets
are separate configuration. They restrict when Renovate may create or update
branches, but do not start a job. Schedule the CronJob often enough for it to
run during the desired Renovate window; see the Renovate scheduling guide.
Additional Examples¶
For example, 0 1 * * 0,6 starts the Kubernetes job at 01:00 on weekends.
Cron Syntax¶
* * * * *
- - - - -
| | | | |
| | | | +----- day of the week (0 - 6) (Sunday=0)
| | | +---------- month (1 - 12)
| | +--------------- day of the month (1 - 31)
| +-------------------- hour (0 - 23)
+------------------------- minute (0 - 59)
For example, to run the Renovate job every day at 1:00 AM, set the schedule field to 0 1 * * *.
Other Options¶
See the Kubernetes CronJob documentation and Kubernetes Job documentation for configuration details.
Once you’ve configured the schedule in your values, deploy or update Big Bang with helm install or helm upgrade as usual.
Example Yaml¶
packages:
renovate:
enabled: true
git:
repo: https://repo1.dso.mil/big-bang/product/packages/renovate.git
tag: 46.388.0-bb.0
values:
upstream:
cronjob:
# At 01:00 every day
schedule: "0 1 * * *"
# -- If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions.
suspend: false
annotations: {}
labels: {}
concurrencyPolicy: ""
failedJobsHistoryLimit: ""
successfulJobsHistoryLimit: ""
jobRestartPolicy: Never
jobBackoffLimit: ""
startingDeadlineSeconds: ""
Renovate Configuration for Big Bang Customer Template¶
Package Configuration¶
Example Package Configuration¶
The following example is for a user fork of the customer template. It opens a dependency dashboard issue tracking Big Bang’s own version, and watches for new Big Bang release tags via regexManagers, detailed below. Paths assume the gitRepo/ layout; for the helmRepo/ layout, see the template’s maintained renovate.json5.
{
"baseBranches": ["main"],
"configWarningReuseIssue": false,
"dependencyDashboard": true,
"dependencyDashboardHeader": "- [ ] Review Big Bang changelog/release notes.",
"dependencyDashboardTitle": "Renovate: Upgrade Big Bang",
"draftPR": true,
"enabledManagers": ["regex"],
"labels": ["renovate"],
"commitMessagePrefix": "",
"separateMajorMinor": false,
"packageRules": [
{
"groupName": "Big Bang",
"matchDatasources": ["git-tags"]
}
],
"regexManagers": [
{
"fileMatch": ["^gitRepo/base/kustomization\\.yaml$"],
"matchStrings": [".+?ref=+(?<currentValue>.+)"],
"depNameTemplate": "https://repo1.dso.mil/big-bang/bigbang.git",
"datasourceTemplate": "git-tags",
"versioningTemplate": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)$"
},
{
"fileMatch": ["^gitRepo/dev/kustomization\\.yaml$"],
"matchStrings": ["tag:\\s+\"(?<currentValue>.+)\""],
"depNameTemplate": "https://repo1.dso.mil/big-bang/bigbang.git",
"datasourceTemplate": "git-tags",
"versioningTemplate": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)$"
},
{
"fileMatch": ["^gitRepo/dev/configmap\\.yaml$"],
"matchStrings": [
"git:\\s+repo:\\s+(?<depName>.+)\\s+tag:\\s+\"(?<currentValue>.+)\""
],
"datasourceTemplate": "git-tags",
"versioningTemplate": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)-bb\\.(?<build>\\d+)$"
}
]
}
RegEx Managers¶
This is where the majority of Big Bang-specific configuration work happens: regex-based rules that tell Renovate which files to watch and how to extract the current version from each.
In this example, the version of Big Bang tracked by gitRepo/base/kustomization.yaml is the target. The regex matches the ref in a line like - git::https://repo1.dso.mil/big-bang/bigbang.git//base?ref=1.41.0, capturing the version number as currentValue:
- git::https://repo1.dso.mil/big-bang/bigbang.git//base?ref=1.41.0
└──┬──┘
captured as currentValue
{
"fileMatch": ["^gitRepo/base/kustomization\\.yaml$"],
"matchStrings": [".+?ref=+(?<currentValue>.+)"],
"depNameTemplate": "https://repo1.dso.mil/big-bang/bigbang.git",
"datasourceTemplate": "git-tags",
"versioningTemplate": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)$"
}
The same pattern applies to gitRepo/dev/kustomization.yaml, or the kustomization for any environment-specific folder.
Targeting an individual package (rather than Big Bang itself) needs a more complex regex, since you’re matching git.tag where git.repository matches the depName:
{
"fileMatch": ["^gitRepo/dev/configmap\\.yaml$"],
"matchStrings": [
"git:\\s+repo:\\s+(?<depName>.+)\\s+tag:\\s+\"(?<currentValue>.+)\""
],
"depNameTemplate": "https://repo1.dso.mil/big-bang/product/packages/kyverno.git",
"datasourceTemplate": "git-tags",
"versioningTemplate": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)-bb\\.(?<build>\\d+)$"
}
packages:
kyverno:
git:
repo: https://repo1.dso.mil/big-bang/product/packages/kyverno.git
tag: "3.9.2-bb.0"
The fileMatch array selects which files to scan, using a regex path relative to the repository root — for example, ["^chart/values\\.yaml$"] matches only chart/values.yaml. matchStrings then needs specific named capture groups for Renovate to understand what it’s looking at:
<currentValue>: the dependency’s current version or tag (e.g.,v1.2.3).<datasource>: the dependency type — for Big Bang packages, usegit-tags.<depName>: the dependency’s name, used as the repository lookup key.<currentDigest>(optional): a SHA256 image digest, if you want Renovate to update that instead of a tag.
Use regex named groups to capture these. See Renovate’s regexManagers reference for the full syntax.
Package Configuration Options¶
See Renovate’s configuration options for details on available package configuration options.