Closed astellingwerf closed 1 year ago
This is not a bug, last package rule wins.
This is not a bug, last package rule wins.
But last package rule doesn't apply, right? They both have a matchCurrentVersion
, of which only one matches the current version.
My suspicion is on line 295 of lib/modules/datasource/index.ts. Based on whatever config
is used for the first fetch of releases for a package, the replacementName
and replacementVersion
are applied to the object. That object is then stored in cache. Whatever other dependency (with its own config, not necessarily with the same replacement settings) for the same datasource
+ packageName
then retrieves the cached entry, with the replacementName
and replacementVersion
originating from a entirely different configuration.
@JamieMagee, can you explain why the replacements are applied at the datasource fetching stage?
Edited to add: I now see that 9 months ago, @rarkins already had a hunch that the datasource might not be the right place to implement this feature.
Sorry for the long wait on this one. I declared GitHub notification bankruptcy a while ago.
I think it was conceptually the right place to apply replacements, as we wanted to override any other version that may be pulled from the datasource. Unfortunately, this appears to be bleeding over package rules as a result.
I'd appreciate any input you have on the design, and I'm open to refactoring this code, cache busting, etc. Replacements aren't enabled by default, and are currently marked as experimental, so we have the ability to refactor and fix this.
:tada: This issue has been resolved in version 34.22.1 :tada:
The release is available on:
34.22.1
Your semantic-release bot :package::rocket:
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us what version of Renovate you run.
32.12.0
Please select which platform you are using if self-hosting.
Happens against GitLab (14) and GitHub.
Was this something which used to work for you, and then stopped?
I never saw this working
Describe the bug
(This issue was updated after further investigation. The earlier text blamed multiple package rules, but it later turned out that a single package rule can also invoke the unexpected behavior.)
If a repository has two similar dependencies (different only by semver prerelease / docker compatibility), and one is subject to a replacement package rule, the other one gets updated to a different prerelease / incompatible compatibility.
Relevant debug logs
Logs
``` Status: Downloaded newer image for renovate/renovate:32.12.0-slim DEBUG: Using RE2 as regex engine DEBUG: Parsing configs DEBUG: Checking for config file in /github-action/renovate-config.js DEBUG: File config "config": { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "platform": "github", "username": "renovate@labelvier.nl", "gitAuthor": "Renovate BotHave you created a minimal reproduction repository?
I've created a rep(r)o with just one packageRule.