Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix duplicate Dependabot PRs #3367

Merged
merged 1 commit into from
Jan 6, 2025
Merged

Fix duplicate Dependabot PRs #3367

merged 1 commit into from
Jan 6, 2025

Conversation

ppkarwasz
Copy link
Contributor

Since Dependabot cannot handle multiple versions of the same artifact at once, our Dependabot configuration for 2.x is split into two runs:

  • One Dependabot run handles the dependency upgrades for the log4j-slf4j-impl (based on SLF4J 1.x) and log4j-mongodb4 (based on MongoDB client 4.x).
  • A second Dependabot run handles the dependency upgrades for the remaining modules (which use SLF4J 2.x and MongoDB client 5.x).

Unfortunately, due to the way Maven multi-module support is implemented in Dependabot (see dependabot/dependabot-core#222), the second Dependabot configuration also tries to upgrade the dependencies of log4j-slf4j-impl and log4j-mongodb4. This is due to the inclusion of the aggregator POM /pom.xml, which causes Dependabot to also include all the remaining Log4j modules. The easiest solution to this problem is to remove "/" from the second configuration.

Pros:

  • 99% of our managed dependencies are in "/log4j-parent" or the individual modules, so we will not miss many upgrades.
  • No more duplicate PRs.

Cons:

  • "pom.xml" contains some dummy managed dependencies to upgrade the version number of commons-csv and similar artifacts for site-only purposes. IMHO we should find a different way to upgrade these.

Since Dependabot cannot handle multiple versions of the same artifact at once, our Dependabot configuration for `2.x` is split into two runs:

- One Dependabot run handles the dependency upgrades for the `log4j-slf4j-impl` (based on SLF4J 1.x) and `log4j-mongodb4` (based on MongoDB client 4.x).
- A second Dependabot run handles the dependency upgrades for the remaining modules (which use SLF4J 2.x and MongoDB client 5.x).

Unfortunately, due to the way Maven multi-module support is implemented in Dependabot (see dependabot/dependabot-core#222), the second Dependabot configuration also tries to upgrade the dependencies of `log4j-slf4j-impl` and `log4j-mongodb4`. This is due to the inclusion of the aggregator POM `/pom.xml`, which causes Dependabot to also include all the remaining Log4j modules. The easiest solution to this problem is to remove "/" from the second configuration.

Pros:

- 99% of our managed dependencies are in "/log4j-parent" or the individual modules, so we will not miss many upgrades.
- No more duplicate PRs.

Cons:

- "pom.xml" contains some dummy managed dependencies to upgrade the version number of `commons-csv` and similar artifacts for **site-only** purposes. IMHO we should find a different way to upgrade these.
@ppkarwasz ppkarwasz requested a review from vy January 6, 2025 14:21
@vy
Copy link
Member

vy commented Jan 6, 2025 via email

@ppkarwasz
Copy link
Contributor Author

(KO’ed by flu. Responding from bed.)

Get better soon!

Changes LGTM. I think we should later move the site from root to a leaf module. This might help us to implement “site should run after all modules”, which is a manual practice currently.

I am glad you agree. Having a dedicated site module can solve many problems, e.g., we could build the website with a simple ./mvnw site without a compulsory ./mvnw verify first.

@ppkarwasz ppkarwasz merged commit 8908092 into 2.x Jan 6, 2025
9 checks passed
@ppkarwasz ppkarwasz deleted the fix/2.x/dependabot branch January 6, 2025 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants