-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support registryUrls using regex manager #6130
Comments
This is not currently possible, so I moved it as a feature request into the main repo. Because |
@rarkins thanks for the super quick response. {
"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?
|
I think it might work if you take the |
Could you possibly provide an example for that please? I'm new to this tool. Thanks! @rarkins |
|
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 |
This config is working for me if anyone reading this is interested. The first regexManager is capturing HelmReleases which use chart repositories (specified in {
"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? |
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 |
A single registryUrl per chart, yes, not a single one for all the charts. |
@Djiit does this not work for you? #6130 (comment) |
@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: #6130 (comment) |
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 |
🎉 This issue has been resolved in version 23.85.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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: Does that clarify? |
Oh allright. This would work, right ?
|
Yes, we decided to keep it simple and not have a |
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:
Current progress with
renovate.json
:The text was updated successfully, but these errors were encountered: