Skip to content

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, use git-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.