How to enable only a smaller subset dependencies: observing disabled dependencies despites package precedence rules ?

[gberche-orange]

How are you running Renovate?

None

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.100.0

Please tell us more about your question or problem

Renovate is awesome. Working on a mono repo with many dependencies (> 500), I'm trying to find ways to speed up feedback on config changes. I started working on a fork, with local branches modifying config to enable a smaller subset of dependencies, and test focused config changes.

I tried to use package rules to disable all packages and then enable selected dependencies, leveraging the documented package rules precedence at https://docs.renovatebot.com/configuration-options/#packagerules

packageRules is a collection of rules, that are all evaluated. If multiple rules match a dependency, configurations from matching rules will be merged together. The order of rules matters, because later rules may override configuration options from earlier ones, if they both specify the same option.

the following syntax is not producing desired effect and enabled packages are reported as skipped with a "skipReason": "disabled"

 "packageRules": [
      {
        "matchPackageNames": [
          "**"
        ],
        "enabled": false
      },
      {
        "matchPackageNames": [
          "kyverno"
        ],
        "enabled": true
      },
      {
        "matchPackageNames": [
          "derailed/popeye"
        ],
        "enabled": true
      },
      {
        "matchPackageNames": [
          "nginx"
        ],
        "enabled": true
      },

It seems that the package names are correct from the logs, so the matchPackageNames with exact match seem correct. I tried to read the DEBUG logs in the renovate logs for hints on other config mistakes I may have done in the remaining of the config.

The full logs are available to mend team in the job id: 80a5eead-4c9c-4289-90c4-7eb86502612c or job id: 454f5ba0-1298-4c09-8334-2d82ad45d3b1

Surprisingly, the job id: 80a5eead-4c9c-4289-90c4-7eb86502612c with the same Post-massage config isn't reporting dependencies as skipped. It was however:

• triggered just after that the create-config-migration-pr checkbox on the dependency issue was clicked, see screenshot
• running renovate version 43.102.11

alternative syntax

• I tried to reverse the order of the rules, which autoclosed all previous PRs, hinting me that the rules are in the right order
• I plan to try a single package rule to enable/disable dependencies instead of multiple package rules.

further diagnotics

The config is using the old syntax, and is not yet migrated, as it was waiting for #38646 recently merged. I plan to check whether the problem reproduces after migrating to new syntax.

I suspect I may have a mistake in the config explaining the observed behavior, but I'm lacking ways to identify it.

I read with interest the post by @jamietanna in #41753 to locally run renovate in order to get more insight on config mistakes I could have done. Unfortunately, I don't yet meet the environment prerequisites for running locally renovate.

Logs (if relevant)

Extract of logs showing associated packages being disabled

        "deps": [
          {
            "autoReplaceStringTemplate": "{{depName}}{{#if newValue}}:{{newValue}}{{/if}}{{#if newDigest}}@{{newDigest}}{{/if}}",
            "currentDigest": "sha256:1beed3ca46acebe9d3fb62e9067f03d05d5bfa97a00f30938a0a3580563272ad",
            "currentValue": "1.29.3",
            "datasource": "docker",
            "depName": "nginx",
            "packageName": "nginx",
            "replaceString": "nginx:1.29.3@sha256:1beed3ca46acebe9d3fb62e9067f03d05d5bfa97a00f30938a0a3580563272ad",
            "skipReason": "disabled",
            "updates": []
          },

        "deps": [
          {
            "autoReplaceStringTemplate": "{{depName}}{{#if newValue}}:{{newValue}}{{/if}}{{#if newDigest}}@{{newDigest}}{{/if}}",
            "datasource": "docker",
            "depName": "derailed/popeye",
            "packageName": "derailed/popeye",
            "replaceString": "derailed/popeye",
            "skipReason": "disabled",
            "updates": []
          },

{
        "deps": [
          {
            "currentValue": "3.5.2",
            "datasource": "helm",
            "depName": "kyverno",
            "packageName": "kyverno",
            "registryUrls": [
              "https://kyverno.github.io/kyverno/"
            ],
            "skipReason": "disabled",
            "updates": []
          }
        ],

[RahulGautamSingh]

@gberche-orange Let's not mention/tag maintainers.

Seems like the issue should be reproducible, please make one. I'll debug and replicate from there.

[gberche-orange]

The problem continues to reproduce on hosted mend on that single repo, for instance in job id 96fce86e-795f-42ca-824a-6ddb0676cb80 with a newer dependency recently enabled in renovate.json

It does not reproduce when running renovate docker image version "43.122.0" against the same repo content.
It does not reproduce on mend.io on a distinct repo with the same renovate.json and sample file to update.

It behaves like if the package rules within renovate.json are pulled from a stale cache instead of the renovate.json file

Extract from logs:

DEBUG: Detected config in env RENOVATE_CONFIG
...
    "repositoryCache": "enabled",
    "cacheTtlOverride": {
      "datasource-docker-hub-tags": 90,
      "datasource-maven:metadata-xml": 90
    },
...
    "repositoryCacheType": "local",
DEBUG: File config
...
"redisUrl": ...
DEBUG: Using configured cacheDir: /runner/cache
DEBUG: Using containerbaseDir: /runner/cache/containerbase
DEBUG: Redis cache init
DEBUG: Redis cache connected


DEBUG: Repository cache is restored from revision 13
DEBUG: http cache: Using cached response: https://api.github.com/repos/orange-cloudfoundry/paas-templates-private-renovate-preview/contents/renovate.json from 2026-04-15T14:37:49.727Z
DEBUG: Existing config file confirmed
DEBUG: Repository config
      {
        "matchDepNames": [
          "pivotal-cf/cf-rabbitmq-smoke-tests-release"
        ],
        "enabled": true
      },

DEBUG: Repo is onboarded
DEBUG: http cache: Using cached response: https://api.github.com/repos/orange-cloudfoundry/paas-templates-private-renovate-preview/contents/renovate.json from 2026-04-16T07:43:17.652Z
DEBUG: Post-massage config
    "packageRules": [
      {
        "matchPackageNames": [
          "**"
        ],
        "enabled": false
      },
...
 {
        "matchPackageNames": [
          "pivotal-cf/cf-rabbitmq-smoke-tests-release"
        ],
        "enabled": true
      },

DEBUG: Cached extract for sha=27653e9f3ba42d18eb2a0811699d27a5b567b7a9 is valid and can be used
{
  "baseBranch": "feature-bumps"
}

DEBUG: Deleted cached dep updates
{
  "baseBranch": "feature-bumps"
}

....

          {
            "currentValue": "267.0.0",
            "datasource": "github-tags",
            "depName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "extractVersion": "^v(?<version>.*)",
            "packageName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "replaceString": "    repository: pivotal-cf/cf-rabbitmq-smoke-tests-release\n    skip_branch_checkout: false\n    version: 267.0.0\n",
            "skipReason": "disabled",
            "versioning": "loose",
            "updates": []
          },

I tried to learn more about Renovate cache, here are somewhat related resources

• Document Renovate caching #22284
• docs(cache): add more information on the different cache(s) and what gets used where #41456
• Clean up repo http cache after each run #27032
• fix(cache): add extract revision, stop deleting skipReason #33172
• How can I invalidate the config cache? #42535

Edit: modified job id from cdc4862c-ebe6-47fb-9a20-097294fb53dd to 96fce86e-795f-42ca-824a-6ddb0676cb80 and matchPackageName extract since initial comment

[gberche-orange]

Rather reproduced in mend.io job id 96fce86e-795f-42ca-824a-6ddb0676cb80, my original comment #42352 (reply in thread) on Apr 15, 18:38 pm GMT+2 had invalid renovate.json logic, I have edited it since.

[RahulGautamSingh]

It does not reproduce when running renovate docker image version "43.122.0" against the same repo content.

We just pushed versions > 43.122.0 to the mend-app. Please check if this still appears and comment incase the issue is not resolved.

[gberche-orange]

I worked around with the following syntax change which apparently cleared the cache in mend.io build

  "packageRules": [
    {
      "matchPackageNames": ["**"],
      "enabled": false
    },
    {
      "matchPackageNames": [ "kyverno", "derailed/popeye", "nginx", "pivotal-cf/cf-rabbitmq-smoke-tests-release", "rancher2" ],
      "enabled": true
    },

Following merge on the default branch

Two builds triggered

with very close timestamps

The first build is picking up the changes, it has job id 3aae93f0-ddc7-4ebb-b3d3-735b720a6468

DEBUG: http cache: saving https://api.github.com/repos/orange-cloudfoundry/paas-templates-private-renovate-preview/contents/renovate.json (etag="73bcc1458fd81d1d5b007130cd0215f723861cf1", lastModified=Thu, 16 Apr 2026 16:19:47 GMT)
DEBUG: Existing config file confirmed
DEBUG: Repository config
...
    "packageRules": [
      {
        "matchPackageNames": [
          "**"
        ],
        "enabled": false
      },
      {
        "matchPackageNames": [
          "kyverno",
          "derailed/popeye",
          "nginx",
          "pivotal-cf/cf-rabbitmq-smoke-tests-release",
          "rancher2"
        ],
        "enabled": true
      },


...
          {
            "currentValue": "267.0.0",
            "datasource": "github-tags",
            "depName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "extractVersion": "^v(?<version>.*)",
            "packageName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "replaceString": "    repository: pivotal-cf/cf-rabbitmq-smoke-tests-release\n    skip_branch_checkout: false\n    version: 267.0.0\n",
            "skipReason": "disabled",
            "versioning": "loose",
            "updates": []
          },

and resulted in the expected dependency extraction not skipped

          {
            "currentValue": "267.0.0",
            "currentVersion": "267.0.0",
            "currentVersionAgeInDays": 42,
            "currentVersionTimestamp": "2026-03-05T10:10:21.000Z",
            "datasource": "github-tags",
            "depName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "extractVersion": "^v(?<version>.*)",
            "fixedVersion": "267.0.0",
            "isAbandoned": false,
            "isSingleVersion": true,
            "mostRecentTimestamp": "2026-04-14T21:12:54.000Z",
            "packageName": "pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "registryUrl": "https://github.com",
            "replaceString": "    repository: pivotal-cf/cf-rabbitmq-smoke-tests-release\n    skip_branch_checkout: false\n    version: 267.0.0\n",
            "sourceUrl": "https://github.com/pivotal-cf/cf-rabbitmq-smoke-tests-release",
            "versioning": "loose",
            "warnings": [],
            "updates": [
              {
                "bucket": "major",
                "newVersion": "269.0.0",
                "newValue": "269.0.0",
                "releaseTimestamp": "2026-04-14T21:12:54.000Z",
                "newVersionAgeInDays": 1,
                "newMajor": 269,
                "newMinor": 0,
                "newPatch": 0,
                "updateType": "major",
                "isBreaking": true,
                "libYears": 0.11084960045662101,
                "branchName": "renovate/pivotal-cf-cf-rabbitmq-smoke-tests-release-269.x"
              }
            ]
          },

Previous mend.io build was job id 96fce86e-795f-42ca-824a-6ddb0676cb80 mentioned at #42352 (reply in thread)

[gberche-orange]

We just pushed versions > 43.122.0 to the mend-app. Please check if this still appears and comment incase the issue is not resolved.

Thanks, the problem was reproducing in 43.122.0 executed in Jod id 96fce86e-795f-42ca-824a-6ddb0676cb80 run at Apr 16, 2026, 09:43:24 GMT+2 with detailed comments in #42352 (reply in thread) and #42352 (reply in thread)

I'll feedback in the coming days if I still manage to reproduce the suspected caching problem

[github-actions[bot]]

Hi there,

This is intended as a polite, automated request that users avoid @ mentioning repository maintainers like @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

We know it might be common elsewhere but we participate in hundreds of discussions a week and would need to turn off GitHub mobile notifications if we were mentioned in every one.

As a general rule, we will read and respond to all discussions in this repository, so there is no need to mention us.

Thanks, the Renovate team

[github-actions[bot]]

Hi there,

Please help this Discussion progress by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the reproduction in your own repository. Ensure it's actually minimal (no unnecesary dependencies or config), or it will be rejected by maintainers.
5. Install the Renovate app to verify that what you say happens (or doesn't happen) reproduces.
6. Fill out the information in your repository's README.md. What you describe there should reflect what you see in this repo, with the hosted app, and not what you saw in your original repo/environment.
7. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.
8. Add a Discussion comment mentioning that the reproduction repo is now available and linked.

If you need help with running Renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team