Robust way to determine configuration priority

[nikfot]

How are you running Renovate?

self-hosted

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

39.107.0

Please tell us more about your question or problem

TL;DR

I have a packageRule with pinDigests: false in aconfig base file. When I use it to extend local renovate config along with config:best-practices , then best practices can shadow the pinDigests: false

Description

In my base.json I have something similar to this in rules:

  "packageRules": [
    {
      "matchDatasources": [
        "docker"
      ],
      "matchManagers": [
        "custom.regex"
      ],
      "matchPackageNames": [
        "example/img-*"
      ],
      "prBodyNotes": [
        "Lorem ipsum odor amet, consectetuer adipiscing elit."
      ],
      "replacementNameTemplate": "{{{replace 'example/img-' 'example/new-' packageName}}}",
      "replacementVersion": "latest",
      "pinDigests": false,
      "enabled": true
    }
  ]

I was supposing that if the scope is more specific it would take precedence. So in this case I would expect that if I include both matchDatasource and matchPackageNames it would be skip pinning digests and not apply the docker:pinDigests that is included in the best practices.

I can move forward by changing the order of best-practices and base.
So instead of doing this:

  "extends": [
    "local>example/config:base",
    "config:best-practices"
  ]

I can do this:

  "extends": [
    "config:best-practices",
    "local>example/config:base"
  ]

But it looks a bit error prone so I would like to know if there is a more robust way to do it.

Logs (if relevant)

Logs

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

[rarkins]

Rules are evaluated in order, and the last applied rule "wins" if more than one rule have conflicting settings. I don't understand why you don't consider such an order of precedence to be non "robust".

[rarkins]

Sorry, but I disagree. If you were to have both order of precedence as well as the ability to influence priority, it could increase complexity and confusion a lot and be the opposite of robust.

Rules are executed in order. Last one wins. Once you understand this, it's simple and robust.

[jamietanna]

Would there be appetite for being able to add a finalExtends or finalPackageRules (naming very much needs improvement) which would allow running any rules at the highest precedence (aka running last)?

This would allow overriding rules taken in the following precedence order:

• globalExtends
• extends
• Repo config

This would only make sense for Self-Hosting Configuration, where as an organisation, we may want to stop accidentally re-enabling rules that don't make sense.

Or would this go against the way that we want a Repo config to be able to override any rules?

(Per your comment, Rhys, looks like no, we don't want to do that - that's fine, we wanted to check!)

[rarkins]

@jamietanna I'm actually open to this idea (of overriding rule priority) to overcome edge cases but I completely disagree that it would be simpler or "robust" - it would be the opposite. Adding the ability to make earlier rules more important would be akin to the z-index in CSS which is terribly ugly and painful. You'd switch to people complaining that their repo config isn't taking effect because someone added zIndex=99 to some central preset.

BTW it hasn't been mentioned here but Renovate's force: {} concept can sometimes achieve the same (same power, same confusion).

[jamietanna]

I assumed (based on some previous experience) that using force: { packageRules: [ ... ] } didn't merge correctly, but it's likely I'm misremembering here.

If it is possible that we could - via our global self-hosting configuration - specify the packageRules we want to have enforced, then this would work for our use-case

[jamietanna]

terribly ugly and painful. You'd switch to people complaining that their repo config isn't taking effect because someone added zIndex=99 to some central preset

100% empathise with this point of view, and given y'all (Renovate maintainers) will feel a lot of the brunt of it, I agree that we should try and find something that doesn't ramp up help requests / increased complexity for the Renovate codebase + users