Infra: Create dedicated Dependabot group for Spring dependencies

[yeikel]

What changes did you make? (Give an overview)

While Dependabot's grouped updates can be convenient, they should be used with care, particularly in projects with a large number of dependencies like this one.

Grouped updates often combine changes that are not compatible with each other, which can make upgrades more difficult and increase the risk of breaking the build. For instance, #1163 includes over 20 updates, and it's not surprising that the build is currently failing. Reviewing and validating that many changes at once is a significant challenge.

This pull request takes an initial step toward organizing updates into smaller, more focused groups, beginning with Spring . Spring was selected because it is both a common source of security advisories and a foundational component of the project’s that should be updated regularly.

Ultimately, we are using grouped dependencies for convenience, but it should not cause us to miss critical upgrades due to the nature and complexity of the groups as the project's complexity grows

How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

• Manually merging this pull request into my fork

It created this pull request: https://github.com/yeikel/kafka-ui/pull/197/files

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
• My changes generate no new warnings (e.g. Sonar is happy)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

A picture of a cute animal (not mandatory but encouraged)

[Haarolean]

Yeah, so the idea why I've grouped all (!) the dependency bumps in a single group is to reduce dependabot's PR spam. I thought we would've excluded the dependencies causing build/test failures from this chonky PRs, but neither we had much time addressing single-dependency PRs before, nor we do have for this chonks now.
Why this supposed to work fine with security updates is that dependabot creates separate PRs for security bumps anyway, that's why it wasn't considered a problem.

I agree with the approach overall, let's start creating some dedicated groups.

[yeikel]

Yeah, so the idea why I've grouped all (!) the dependency bumps in a single group is to reduce dependabot's PR spam. I thought we would've excluded the dependencies causing build/test failures from this chonky PRs, but neither we had much time addressing single-dependency PRs before, nor we do have for this chonks now. Why this supposed to work fine with security updates is that dependabot creates separate PRs for security bumps anyway, that's why it wasn't considered a problem.

I agree with the approach overall, let's start creating some dedicated groups.

Thank you for the explanation. I understand that dependabot pull requests can overwhelm the maintainers for such a large project like this. Let's start small with two groups for now and we can iterate as we see fit

Thank you again!

[yeikel]

@Haarolean What blocks merging this one? I have at least 2 follow up PRs planned after this one

Thanks again!