Duplicate PRs for same dependency in same folder

[spnda]

Is there an existing issue for this?

• [X] I have searched the existing issues

Package ecosystem

Gradle

Package manager version

7.6

Language version

Java 17 / Kotlin DSL

Manifest location and content before the Dependabot update

I have three manifests: /build.gradle.kts, /common/build.gradle.kts, /spigot/build.gradle.kts.

dependabot.yml content

https://github.com/spnda/BlockProt/blob/master/.github/dependabot.yml

Updated dependency

org.jetbrains:annotations:23.0.0 -> org.jetbrains:annotations:23.1.0

What you expected to see, versus what you actually saw

Within the dependabot manifest file, I specify each subdirectory for the two manifests that are not in the root directory. I did this, because I can't find any reference to the directory search for a build.gradle{.kts} to look in subdirectories. Dependabot, however, opened two PRs with the same dependency update for a dependency in /common/ (which is not mentioned in the root manifest). One of the PRs title includes "in /common", while the other one doesn't. This could make sense, if we assume that dependabot has changed that it now searches through subdirectories for manifests. However, in the screenshot below you can see another PR was opened for another dependency in /spigot/. For this dependency, there was no second PR, suggesting that it doesn't always search for subdirectories.

Native package manager behavior

N/A

Images of the diff or a link to the PR, issue, or logs

The 3 PRs shown in the image before can be found here: https://github.com/spnda/BlockProt/pulls

Smallest manifest that reproduces the issue

Look at my manifest file linked above, and now create the two manifest files, one in root one in common with a dependencies { api("org.jetbrains:annotations:23.0.0") }. That should be enough to spark the bug, however, as I mentioned before, there seems to be cases where this bug does not occur.

[spnda]

It just did the same thing again. spnda/BlockProt#210 and spnda/BlockProt#212. Seems to not happen with any other dependency.

[jeffwidman]

Does it reproduce using the dry-run or CLI script? See https://github.com/dependabot/dependabot-core#debugging-problems for instructions.

TBH, this probably isn't something the core team will have a chance to look at closely anytime soon, but if you want to use one of the above tools to try to dig in further, we're happy to answer any questions. This is open source, so you can use debugger breakpoints etc and might be able to narrow it down further?

[jwodder]

I'm experiencing a similar problem with some Python projects of mine. Each project is located at its repository root, which contains a pyproject.toml file; each project also contains a docs/ directory with a docs/requirements.txt file inside that uses ~= ("is compatible with") as the version operator in all of its entries. I would like both the pyproject.toml and docs/requirements.txt files to only be updated when an incompatible release is made of a dependency listed therein, and so I currently have the following .github/dependabot.yml file:

version: 2
updates:
  - package-ecosystem: pip
    directory: /
    schedule:
      interval: weekly
    commit-message:
      prefix: "[python]"
    labels:
      - dependencies
      - d:python

  - package-ecosystem: pip
    directory: /docs
    versioning-strategy: increase-if-necessary
    schedule:
      interval: weekly
    commit-message:
      prefix: "[python+docs]"
    labels:
      - dependencies
      - d:python

However, new versions of dependencies listed in docs/requirements.txt end up getting two PRs created: one for the / block and one for the /docs block. Examples: a PR for the /docs block and another PR created at the same time that does the same thing, but associated with the / block.

In addition, it seems that the / block ends up applying an increase versioning strategy to docs/requirements.txt, and so, whenever a dependency listed in docs/requirements.txt gets a new version released that is still compatible with the one listed in the file, an update PR (which I do not want) will be created that is associated with the / block, while no PR will be created for the /docs block (as it should be).