Shared config cached / Support for weird Docker tags?

[ro0NL]

What would you like help with?

I would like help with my configuration

How are you running Renovate?

Mend Renovate hosted app on github.com

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

We're using a shared global renovate config from a dedicated repo.

We've patch it, while leaving the project's config untouched.
However, im not sure changes are taken into in effect during the next project run.

Am i right to think the global config is cached, and isnt invalidated in this case or so?

Logs (if relevant)

Logs

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

[rarkins]

I don't think it's cached.

[ro0NL]

Interesting, ive patched the versioning schema for minio/minio:

        {
            "matchDepNames": [
                ...
                "minio/minio"
            ],
            "versioning": "loose"
        },

but in the logs i see versioning docker:

            "depName": "minio/minio",
            "packageName": "minio/minio",
            "replaceString": "minio/minio:RELEASE.2024-06-13T22-53-53Z",
            "skipReason": "invalid-value",
            "versioning": "docker",

[ro0NL]

@rarkins it works if i update the project's renovate config.

So inheriting from the global config totally broke somehow, which likely lead to #29790 as well.

Our shared repo has default.json in root as per https://docs.renovatebot.com/config-presets/, but also a .github/renovate.json which extends from itself

[ro0NL]

i think after removing custom changelog mappings from the global package rules, it started working

i see "versioning": "loose", in logs now, but it's already outdated compared to GIT. So definitively some cache going on still.

[ro0NL]

ive enabled the same package rule in project's config, that invalidated cache.

then i reverted it, and it seems to properly pickup the same shared package rule now

it's a bit of black box, but i think it works now.

if not, we'll duplicate the shared package rule per project and move on