Add matchRegistryUrls option to packageRules

[lindhe]

Tell us more.

It would be helpful to me to be able to match on registryUrl in packageRules. I suggest we add that. I'm not familiar enough with the renovate codebase to implement it myself, but I'm happy to help if I can.

The idea was briefly mentioned here, but I think it never came to fruition.

[rarkins]

Once you match, what would you want renovate to do? Please create a real packageRules example of how you'd use it

[rarkins]

In this case it could be applied after lookup. I wasn't sure if you were trying to influence lookup.

[viceice]

what's the package name in the logs? it's probably different and longer, so easier to match.

[lindhe]

Running with LOG_LEVEL=debug, this is the deps list:

{
  "deps": [
    {
      "depName": "core",
      "currentValue": "2.7.3",
      "registryUrls": ["https://neuvector.github.io/neuvector-helm"],
      "datasource": "helm",
      "depType": "HelmChart",
      "updates": [
        {
          "bucket": "non-major",
          "newVersion": "2.7.7",
          "newValue": "2.7.7",
          "newDigest": "1f38c9cfe24767fd2e86b94776927756772df5ee9b23754c52319afe1ffdcb9f",
          "releaseTimestamp": "2024-06-07T22:26:34.255Z",
          "newMajor": 2,
          "newMinor": 7,
          "newPatch": 7,
          "updateType": "patch",
          "branchName": "renovate/core-2.x"
        }
      ],
      "packageName": "core",
      "versioning": "helm",
      "warnings": [],
      "registryUrl": "https://neuvector.github.io/neuvector-helm",
      "homepage": "https://neuvector.com",
      "currentVersion": "2.7.3",
      "currentVersionTimestamp": "2024-02-08T19:11:29.379Z",
      "isSingleVersion": true,
      "fixedVersion": "2.7.3"
    }
  ],
  "packageFile": "manifests/neuvector/base/kustomization.yaml"
}

[lindhe]

Here's what my kustomization.yaml looks like:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmCharts:
- includeCRDs: true
  name: core
  namespace: cattle-neuvector-system
  releaseName: neuvector
  repo: https://neuvector.github.io/neuvector-helm
  valuesFile: values.yaml
  version: 2.7.3

[lindhe]

Typically, this repo would be added using helm repo add neuvector https://neuvector.github.io/neuvector-helm and then the chart can be referred to using neuvector/core, which makes sense. But naming the repo "neuvector" is just a convention not something that can be determined automatically. Especially when using Kustomize like this, where the repo link is used directly rather than first adding it with some name.

In my particular case, it would make sense to extract the releaseName and use as part of the package name, but that's not true in general.

Come to think about it, this is part of a more general problem! When Renovate first discovered this dependency for me, it posted a PR with title chore(deps): update Helm Chart core to v2.7.7. I didn't like that, so I modified my renovate.json to make it more specific:

{
  "matchManagers": ["kustomize"],
  "commitMessageTopic": "{{prettyDepType}} {{replace '/base$' '' (replace '^manifests/' '' packageFileDir)}}/{{depName}}"
}

Which renders like chore(deps): update helmchart neuvector/core to v2.7.7. But this is also good for my particular case, not generally true.

[programmer314]

This would be useful to me too actually. I can give a go at implementing it if you want, I assume it should follow a similar pattern to the other package rule matchers. I'll describe my use case below.

Basically, I would like to create a package rule in my organization to set a minimum release age for all external dependencies, but get updates for internal dependencies immediately. I already looked into excluding all dependencies with my organization's name in their package name, but we still have a lot of dependencies that don't fall under this criteria. However excluding dependencies with the name in the registry url should do exactly what we need.

Looks like #31625 is dealing with a similar use case actually, so I think it would be useful to a few people.

[andrewducker]

This is exactly what we want to do. Packages coming from the external-cache repo should be delayed 7 days, packages coming from the internal-combined virtual repo should go through instantly.
(And some other things where there are extra steps because we trust external packages less than we trust internal packages.)

[RahulGautamSingh]

Implemented: #41966