Issues with Renovate PR Grouping and Rate-Limiting (need help)

[knuurr]

How are you running Renovate?

A Mend.io-hosted app

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

Issue Description

We are running Mend Renovate Bot to manage updates for dependencies in our infrastructure. Initially, we configured it to apply common update rules to manifests under specific paths in our repository:

    "fileMatch": [
      "argo_clusters/common/apps/.+\\.yaml$",
      "argo_clusters/main/apps/.+\\.yaml$",
      "argo_clusters/manager/apps/.+\\.yaml$",
      "argo_clusters/monitoring/apps.+\\.yaml$"
    ]

These manifests correspond to ArgoCD ApplicationSet definitions. This setup has worked well for a long time, but now we need more granular control over updates for specific manifests due to:

1. Manually Updated Packages

   • Some packages require manual updates due to initial deployment constraints. Migration is not an option right now.
   • We still want Renovate to create PRs for visibility when a new version is available, but without automatically applying updates.

2. Version Information in Non-Standard Locations

   • Some Helm chart templates have custom key-value structures, where the Docker image version is stored differently from standard Renovate expectations. Example:

        image:
              repository: n8nio/n8n
              tag: "1.40.0"

3. Separate PRs for Different Environments
   • Some applications have multiple ApplicationSet manifests for different environments (e.g., testing vs. production).
   • By default, Renovate groups them into a single PR, but we need them to be separate to manage updates independently.

      source:
        chart: victoria-metrics-k8s-stack
        repoURL: https://victoriametrics.github.io/helm-charts/
        targetRevision: 0.37.x # demo file

        targetRevision: 0.38.x # staging
        
        targetRevision: 0.34.x # staging
        # etc...

---

Current Issues with the New Configuration

We have created a Renovate configuration to address these needs, but we are facing several issues:

1. Rate-Limiting for n8n Updates

   • All updates for n8n appear as rate-limited in the Renovate dashboard.
   • Expected behavior: At most one open PR per update type (patch/minor/major) at a time.
   • Current behavior: We must manually rebase PRs, which is inefficient.

2. Same Issue for ArgoCD Updates

   • Similar rate-limiting issue affects ArgoCD version tracking.

3. Unexpected Grouped PRs for victoria-metrics

   • Despite explicit configuration to create separate PRs for victoria-metrics updates, Renovate sometimes creates grouped PRs along with single-file PRs.
   • Not a critical issue, but we would like to understand how to enforce only single-file PRs for victoria-metrics.

---

Desired Outcome

1. Ensure that at most one open PR per update type (patch/minor/major) exists at a time for n8n and ArgoCD.
2. Guarantee that victoria-metrics updates always generate separate PRs per environment, without any grouped PRs.
3. Maintain the notification-only behavior for manually updated packages and EKS addons.

Here is our current Renovate configuration:

Click to expand JSON config

{  
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "description": "Renovate configuration for managing dependencies across our infrastructure",
  "extends": [
    "config:recommended",
    ":assignee(xxxx)",
    ":automergeDisabled",
    ":separateMultipleMajorReleases",
    ":separateMultipleMinorReleases"
  ],
  "baseBranches": ["main"],
  "enabledManagers": [
    "helmfile",
    "helm-values",
    "dockerfile",
    "argocd",
    "kubernetes",
    "custom.regex",
    "regex"
  ],
  "commitMessagePrefix": "{{#if isPatch}}📦{{else}}{{#if isMinor}}⬆️{{else}}⏫{{/if}}{{/if}}",
  "commitMessageAction": "Update",
  "commitMessageTopic": "{{depName}}",
  "commitMessageExtra": "{{currentVersion}} -> {{newVersion}} ({{#if isPatch}}patch{{else}}{{#if isMinor}}minor{{else}}major{{/if}}{{/if}})",
  "argocd": {
    "description": "ArgoCD configuration for scanning Kubernetes manifests in our clusters",
    "fileMatch": [
      "argo_clusters/common/apps/.+\\.yaml$",
      "argo_clusters/main/apps/.+\\.yaml$",
      "argo_clusters/manager/apps/.+\\.yaml$",
      "argo_clusters/monitoring/apps.+\\.yaml$"
    ]
  },
  "prConcurrentLimit": 30,
  "prHourlyLimit": 10,
  "customManagers": [
    {
      "description": "Track n8n version updates in ArgoCD applications",
      "customType": "regex",
      "fileMatch": ["^argo_clusters/.*/apps/n8n\\.yaml$"],
      "matchStrings": ["tag:\\s*['\"](?<currentValue>[^'\"]*)['\"]"],
      "depNameTemplate": "n8nio/n8n",
      "datasourceTemplate": "docker"
    }
  ],
  "packageRules": [
    {
      "description": "n8n major updates",
      "matchDepNames": ["n8nio/n8n"],
      "matchUpdateTypes": ["major"],
      "prPriority": 1,
      "groupName": "n8n major updates",
      "prBodyNotes": ["⚠️ Manual verification required before merging"],
      "prConcurrentLimit": 1,
      "prHourlyLimit": 1
    },
    {
      "description": "Victoria Metrics configuration - separate PRs for each environment",
      "matchDatasources": ["helm"],
      "matchPackageNames": ["victoria-metrics-k8s-stack"],
      "matchPaths": [
        "argo_clusters/common/apps/victoria-metrics.yaml",
        "argo_clusters/monitoring/apps/victoria-metrics.yaml",
        "argo_clusters/common/apps/victoria-metrics-prod.yaml",
        "argo_clusters/monitoring/apps/victoria-metrics-prod.yaml"
      ],
      "groupName": null
    }
  ]
}

---

Request for Help

1. How can we ensure only one open in GitHub, not throttled PR per update type (patch/minor/major) at a time for n8n and ArgoCD?
2. How can we completely prevent grouped PRs for victoria-metrics updates, ensuring only single-file PRs?
3. Is there a better way to structure our Renovate configuration to achieve our desired results?

Any guidance or recommendations would be greatly appreciated.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[github-actions[bot]]

Hi there,

Please stick to one topic/question per Discussion. Start a new discussion per topic.

This prevents future users from finding this discussion and getting confused by multiple questions and answers. One question and answer per Discussion works best.

For example:

• Don't create a discussion with multiple questions requiring multiple answers
• If you got an answer to your first question, don't change topic like "Can I also ask you how I might..." which would then require a different answer. Mark the current discussion as answered and open a new one.

Thanks, the Renovate team

[knuurr]

No problem, will re-create.