GH-395: Add Dependabot support to the project

[artembilan]

Fixes: #395
Issue link: #395

• Added dependabot.yml config for both main and 1.3.x supported branches
• Include updates of package-ecosystem for Gradle and GitHub Actions
• Extract development-dependencies group for those dependencies which are used only for this project development: all the test dependencies, compileOnly and Gradle plugins

Note: had to rename label in project repository to the type: dependency-upgrade and also added type: task

[artembilan]

If that is the right direction, I have a reusable GHA workflow like merge-dependabot-pr.yml: https://github.com/spring-io/spring-github-workflows?tab=readme-ov-file#dependabot-support.
Adding that into the project would simplify the routine a little bit with automatic Dependabot PRs merging if they are green and respective milestone is scheduled.

[violetagg]

@artembilan This configuration will create duplicate PRs for branch 1.3.x and main. For the other Reactor projects we have configuration only for the oldest maintenance branch and then we forward merge the commits. (1.3.x and main do not differ in dependencies)

In Reactor we have an agreement that labels do not contain : - can we rename the new labels

• type: dependency-upgrade to type/dependency-upgrade
• type: task to type/chore

You will need to exclude some versions for certain dependencies e.g. https://github.com/reactor/reactor-pool/blob/main/.github/dependabot.yml

[violetagg]

If that is the right direction, I have a reusable GHA workflow like merge-dependabot-pr.yml: https://github.com/spring-io/spring-github-workflows?tab=readme-ov-file#dependabot-support. Adding that into the project would simplify the routine a little bit with automatic Dependabot PRs merging if they are green and respective milestone is scheduled.

Does this perform forward merge as all Reactor projects does forward merge starting from the oldest maintenance branch to the main? If yes go for it.

[artembilan]

Right. Sorry for my ignorance. I didn't think that other projects may follow different merge approach.
For my other projects where I have 2-3 supporting versions and it is much easier to have PRs for those specific branches.
First of all, no guarantee that all the deps are in the same version, or even those different branches have all the dependencies.
Plus my automatic Depedendabot PRs merge makes life easier with just direct merge those branches without any merge headache.

If that does not work for you, I'll definitely will provide config only for the 1.3.x branch.

Will rename labels shortly.

I don't believe that we need so many ignores, if our schema is like this:

    ignore:
      - dependency-name: '*'
        update-types:
          - version-update:semver-major
          - version-update:semver-minor

So, Dependabot would not look even into a new minor version.
However I might agree that findbugs should be ignored: in other projects we moved to the com.github.spotbugs:spotbugs-annotations.
But that's totally different story, as well as many other deps could be updated/removed.

[violetagg]

yeah a long time ago ... :) we discussed what merge strategy we want to support so we decided to adopt forward merge

[violetagg]

    ignore:
      - dependency-name: '*'
        update-types:
          - version-update:semver-major
          - version-update:semver-minor

This is generally ok although for example for junit we update the minor version, but that's up to you.

[artembilan]

for junit we update the minor version.

From our experience it is better to do such an update in a new our minor version or do that manually to be sure that nothing is broken.
I don't talk specifically about JUnit, but in general how it was painful from time to time to upgrade to a new minor version in the middle of point version.

Since you are looking for forward merge, then we just cannot talk about minor versions at all, even for main.

[artembilan]

Thank you for review, @violetagg !

What is rule, please? Do I merge PR myself?

Might be subsequent changes when Dependabot runs.
How do we handle its PRs afterwards thought?

[violetagg]

Thank you for review, @violetagg !

What is rule, please? Do I merge PR myself?

yes, the one that opened the PR, merges it and does the forward merge (this is for the committers not contributors)

Might be subsequent changes when Dependabot runs. How do we handle its PRs afterwards thought?

If it is something trivial, a direct commit is ok, but typically we use PRs.

PRs are must for bugs/features. When we release the project the release notes are generated based on the PRs.