Renovate: Support registryUrls using regex manager

Created on 5 May 2020  路  26Comments  路  Source: renovatebot/renovate

Which Renovate are you using?

WhiteSource Renovate App

Which platform are you using?

GitHub.com

What would you like to do?

I'm attempting to use the regexManager with the Helm datasource to capture the required values from a Kubernetes HelmRelease CRD in order to select the correct registry, chart name, and version.
So far, I've successfully captured the depName and currentValue, but the registryUrl needs to be specified as a list as per this section of the docs.

I'm not sure how to capture the repository URL as a list using matchStrings, and would appreciate any help in achieving this.

Example HelmRelease CRD:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: prometheus-operator
  namespace: monitoring
spec:
  releaseName: prometheus-operator
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: prometheus-operator
    version: 8.12.13
...

Current progress with renovate.json:

{
  "extends": ["config:base"],
  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: (?<registryUrls>.*?)\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm"
    }
  ]
}
priority-3-normal feature

Most helpful comment

This config is working for me if anyone reading this is interested. The first regexManager is capturing HelmReleases which use chart repositories _(specified in packageRules)_, the second is capturing any HelmReleases using GitHub repos and updating based on tags.

{
  "extends": ["config:base"],
  "kubernetes": {
    "fileMatch": ["\\.yaml$"]
  },
  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: .*?\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm"
    },
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *git: [email protected]:(?<depName>.*?).git\n *ref: (?<currentValue>.*?)\n"
      ],
      "datasourceTemplate": "github-tags"
    }
  ],
  "packageRules": [
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "sealed-secrets",
        "kube-ops-view",
        "metrics-server",
        "prometheus-operator"
      ],
      "registryUrls": ["https://kubernetes-charts.storage.googleapis.com/"]
    },
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "ingress-nginx"
      ],
      "registryUrls": ["https://kubernetes.github.io/ingress-nginx"]
    },
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "external-dns"
      ],
      "registryUrls": ["https://charts.bitnami.com/bitnami"]
    }
  ]
}

All 26 comments

This is not currently possible, so I moved it as a feature request into the main repo. Because registryUrls is technically an array, we need to think how to structure this. One possibility would be to initially support only a single registryUrl and then convert that into an array of length 1 afterwards.

@rarkins thanks for the super quick response.
My initial thought would be to do this for each known repository in the meantime:

{
  "extends": ["config:base"],
  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: https://kubernetes-charts.storage.googleapis.com/\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm",
      "registryUrls": ["https://kubernetes-charts.storage.googleapis.com/"]
    }
  ]
}

I imagine a more permanent solution could be to add a template for registries?
```
{
"extends": ["config:base"],
"regexManagers": [
{
"fileMatch": ["\.yaml$"],
"matchStrings": [
"chart:\n repository: (?.?)\n name: (?.?)\n version: (?.)\n"
],
"datasourceTemplate": "helm",
"registryUrlsTemplate": ["{{registry}}"]
}
]
}

I think it might work if you take the registryUrls part out and put it into a packageRule instead.

Could you possibly provide an example for that please? I'm new to this tool. Thanks! @rarkins

{
  "extends": ["config:base"],
  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: https://kubernetes-charts.storage.googleapis.com/\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm",
    }
  ],
  "packageRules": [{
    "datasources": ["helm"],
    "managers": ["regex"],
    "registryUrls": ["https://kubernetes-charts.storage.googleapis.com/"]
  }]
}

Thanks for that. So, what if there's multiple registries for different HelmReleases? How would I pin that packageRule to a specific regexManager?

You would need to write multiple package rules and match based on packageNames or something like that.

This config is working for me if anyone reading this is interested. The first regexManager is capturing HelmReleases which use chart repositories _(specified in packageRules)_, the second is capturing any HelmReleases using GitHub repos and updating based on tags.

{
  "extends": ["config:base"],
  "kubernetes": {
    "fileMatch": ["\\.yaml$"]
  },
  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: .*?\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm"
    },
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *git: [email protected]:(?<depName>.*?).git\n *ref: (?<currentValue>.*?)\n"
      ],
      "datasourceTemplate": "github-tags"
    }
  ],
  "packageRules": [
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "sealed-secrets",
        "kube-ops-view",
        "metrics-server",
        "prometheus-operator"
      ],
      "registryUrls": ["https://kubernetes-charts.storage.googleapis.com/"]
    },
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "ingress-nginx"
      ],
      "registryUrls": ["https://kubernetes.github.io/ingress-nginx"]
    },
    {
      "datasources": ["helm"],
      "managers": ["regex"],
      "packageNames": [
        "external-dns"
      ],
      "registryUrls": ["https://charts.bitnami.com/bitnami"]
    }
  ]
}

Would love to see this, especially as more and more charts are served from the company's repository and not the stable or bitnami repos.

Edit: for context, with ChipWolf's example I have 8 package rules, not counting stable, with at least two more on the way.

I'd like to see this supported too. Would it be possible to extract the actual repo URL from the yaml file?
I'm willing to help with a little guidance :)

Would support for a single registryUrl satisfy your current use cases?

Also, are you only using the regex manager because if a deficiency in our current Helm or k8s package manager support?

@rarkins Single registryUrl would work for us, and we're suing regex because we're using Helm Operator (and soon Helm Controller) to handle Helm releases. Adding native support for those to Dependabot's Helm support would also work for us, but might not address other abstractions.

@RichiCoder1 I've added a new isue to track the Helm Operator manager. Should be easy to implement, as it's only some simple yaml.

Would support for a single registryUrl satisfy your current use cases?

A single registryUrl per chart, yes, not a single one for all the charts.

@Djiit does this not work for you? https://github.com/renovatebot/renovate/issues/6130#issuecomment-624061289

@ChipWolf Yes! I'd just like to be able to get rid of the redundancy (redeclare registries in renovate.json)

^ Yup. It works, but it's not ideal as I mentioned here: https://github.com/renovatebot/renovate/issues/6130#issuecomment-703041160

Also showing my interest in this there's no doubt @ChipWolf method works but having to redeclare all helm chart sources and apps can get pretty hairy.

It's also worth noting that Flux probably nearing EOL and being replaced with Flux2 in the future.

Defining a HelmRepository in Flux2:

---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: kubernetes-sigs-descheduler-charts
  namespace: flux-system
spec:
  interval: 10m
  url: https://kubernetes-sigs.github.io/descheduler
  timeout: 3m

Sample of a Flux2 HelmRelease:

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: descheduler
  namespace: kube-system
spec:
  interval: 5m
  chart:
    spec:
      chart: descheduler-helm-chart
      version: 0.19.0
      sourceRef:
        kind: HelmRepository
        name: kubernetes-sigs-descheduler-charts
        namespace: flux-system
      interval: 5m
  values:
    image:
      repository: k8s.gcr.io/descheduler/descheduler
      tag: v0.19.0
      pullPolicy: IfNotPresent
    deschedulerPolicy:
      strategies:
        RemoveDuplicates:
          enabled: false
        RemovePodsViolatingNodeAffinity:
          enabled: true
          params:
            nodeAffinityType:
            - requiredDuringSchedulingIgnoredDuringExecution
        RemovePodsViolatingInterPodAntiAffinity:
          enabled: false
        LowNodeUtilization:
          enabled: false

The hack with fluxv2 which worked for me was to put the registry URL commented out above the chart name; not ideal, but it works

heh good idea @ChipWolf :D

:tada: This issue has been resolved in version 23.85.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Hey @rarkins, thank for the PR! Any quick example of how we are supposed to use it ? Thanks

@Djiit this line was added to the docs:

image

Does that clarify?

Oh allright. This would work, right ?

  "regexManagers": [
    {
      "fileMatch": ["\\.yaml$"],
      "matchStrings": [
        "chart:\n *repository: (?<registryUrl>.*?)\n *name: (?<depName>.*?)\n *version: (?<currentValue>.*)\n"
      ],
      "datasourceTemplate": "helm"
    }
  ],

Yes, we decided to keep it simple and not have a registryUrlTemplate field unless it's unavoidable for someone

Was this page helpful?
0 / 5 - 0 ratings