Change in ignorePaths configuration in config:recommended

[amanda-tarafa]

What would you like help with?

I think I found a bug

How are you running Renovate?

None

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 have several repos configured with ignorePaths rules that have been honored by renove for a long time. Starting today, 2024-09-16, we have received several renovate PRs for dependencies specified in ignorePaths:

googleapis/gapic-generator-csharp#834
GoogleCloudPlatform/dotnet-docs-samples#2787

Logs (if relevant)

Logs

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

[github-actions[bot]]

Hi there,

A maintainer decided this is not a bug, and behaving as designed. The maintainer will explain why this behavior is correct. To avoid confusing future readers, we will close this Discussion.

We want Bug-type Discussions to be about things that we rate as bugs. For more details, please read our development docs about bug handling.

If this bug report makes you think of an idea for a new feature, or how to improve a current feature, feel free to create a new Suggest an Idea Discussion.

Thanks, the Renovate team

[rarkins]

the product's defaults

It's not the product's defaults, it's the non-default ignorePaths settings in config:base

[amanda-tarafa]

Let's first understand why this repo needs to ignore test directories as you asked, so we have a fuller picture.

I already replied to this, a few times actually. See #31436 (reply in thread) for some of the use cases where we are ignoring paths, only some of them are test paths.

you are also extending config:base, which is an opinionated preset which includes non-default ignorePaths settings

acked, I'm fine with calling these opinionated presets instead of defaults.

which conflict with your repo configuration

Correction here: Which only yesterday started conflicting with my repo configuration by no action of my own. This makes it a breaking change that you introduced through changes in your opinionated presets. That a component is opinionated does not mean it gets a free pass for introducing breaking changes.

• Extend only the subcomponents of it that you want, or
• Ignore the subcomponents you don't want
  Neither of the above approaches is a "workaround".

For me these are indeed workarounds to fixing a breaking change as that's absolutely the only reason why I would need to use them. Otherwise, I want all the subcomponents as they were previously configured in the opinionated preset I'm extending. The simple prove of that is that everything has been working as expected for years.

And the main worry here is not necessarily having to add a couple more lines to my configs. The main worries are, will this happen again?, will I catch it or will I merge unwanted dependency updates because I'm trusting tooling, etc.? How deep of an understanding do I need of the implementation details of renovate, to make certain I come up with configs that are resilient to preset breaking changes, or should I just simply not use presets if those are subject to breaking changes?

By the way, I've reread some relevant parts of your documentation to figure out whether I might have missed something, and I can't find anything obvious, for instance, in https://docs.renovatebot.com/config-overview/#config-precedence and https://docs.renovatebot.com/key-concepts/presets/. I have no doubt that a renovate expert could have seen this coming, but I also think I shouldn't need to be an expert for having my dependencies updated except for a handful of paths.

[fgreinacher]

(I'm not a maintainer here, just a power user and contributor)

Your use cases are totally clear, thanks!

I also understand the frustration when things that have worked before stop working unexpectedly.

I still think that changing the NuGet setting in the config:base preset makes sense for most users.

In hindsight I'd probably consider this a breaking change. Of course that would not change the situation that some users like you need to adapt their config. But it would at least indicate that changes are needed.

I tend to think that rolling back the change now (deferring it to the next major) would cause more confusion than just keeping it as-is and handling problems like this one on a case-by-case basis 🤔

[rarkins]

Unfortunately in a hosted service, the decision of whether to make it a breaking change or not doesn't really change anything because end users of a hosted service do not have control about when major updates happen. This end user impact is not exclusive to the Mend-hosted app either - it would also apply to all non-admin users in companies who self-host too.

Therefore in a hosted service if you took a strict view on breaking changes then it means you can never change behavior, which means never correcting bad decisions from the past, never changing behavior even if the industry or third parties have changed their default behavior, etc. Ultimately it would satisfy the "never surprise me, never make a breaking change, never make me change my config" type of user, but it would result in a product/service with undesirable behavior (such as ignoring Nuget test folders).

This particular case is not clear cut either - it's more complicated because:

• Renovate defaults didn't actually change
• An opinionated preset changed
• The user of that preset was already overriding an aspect of the preset (the aspect which changed)

BTW I attempted to largely solve this "protect end users from breaking changes" challenge in #25855 some time ago but ultimately didn't progress it. It was inspired partly by how Go uses the go.mod directive to provide "backwards compatible" behavior to projects which were originally written in older versions of Go.

[amanda-tarafa]

Therefore in a hosted service if you took a strict view on breaking changes then it means you can never change behavior,

No, there are many techniques to change behaviour and surface on a hosted service, without breaking users. A quick internet search already yields results for good overviews, and I'm pretty sure there's extensive literture about this. It seems you even tried to implement one particular approach.

The reluctance to call this a breaking change, plus the fact that there's no versioning mechanism implemented to protect users from further breaking changes means this likely will happen again.

But, I need to move on, so I'll be using one of the workarounds. And reconsidering options. Thanks.