Ignores not being applied for Gradle

[eirnym]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

gradle

Package manager version

Gradle 7.6

Language version

Java 17

Manifest location and content before the Dependabot update

Reposistory at relevant commit: https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1/

I have a few separate independent projects inside a single repo: plugin, internal plugin, demo for AGP 7 and java demo.

Repository: https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1/

• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1/settings.gradle.kts
• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1/internal/settings.gradle.kts
• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1//demo/java/settings.gradle.kts
• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1//demo/android/agp7/settings.gradle.kts

plugin contains a few modules, depending on libraries with conflicting API by design, and it working well:

• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1//plugin-gradle/compat/agp34/build.gradle.kts
• https://github.com/jsonschema2dataclass/js2d-gradle/blob/69cf5b5c1b3290301508e98d581f70764771a3f1//plugin-gradle/compat/agp7/build.gradle.kts

dependabot.yml content

# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
  - package-ecosystem: gradle
    directory: "plugin-gradle/compat/agp7"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: com.android.tools.build:gradle
        update-types: [ "version-update:semver-major" ]
  - package-ecosystem: gradle
    directory: "/plugin-gradle/compat/agp34"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: com.android.tools.build:gradle
        update-types: [ "version-update:semver-major" ]
  - package-ecosystem: gradle
    directory: "demo/java"
    schedule:
      interval: "daily"
  - package-ecosystem: gradle
    directory: "demo/android/agp7"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: com.android.tools.build:gradle
        update-types: [ "version-update:semver-major" ]
  - package-ecosystem: "github-actions"
    directory: ""
    schedule:
      interval: "daily"
  - package-ecosystem: gradle
    directory: ""
    schedule:
      interval: "daily"

Updated dependency

No response

What you expected to see, versus what you actually saw

1. Despite on rules created to skip major updates for certain modules, dependabot stubbornly updates the PR for it. example: build(deps): bump gradle from 4.2.1 to 7.4.0 jsonschema2dataclass/js2d-gradle#620 and there's serveral such PR
2. Despite I remove includeBuild from the settings.build.kts for a subproject, it still has an attachment to the root project which is incorrect as well
3. Changes in settings.gradle.kts are ignored while this file defines a gradle project, not build.gradle.kts

Native package manager behavior

No response

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

jsonschema2dataclass/js2d-gradle#620
and few recently closed from dependabot. I ususally merge, not close as in most cases it makes more sence

Smallest manifest that reproduces the issue

No response

[jeffwidman]

Sorry for the slow response. I keep thinking I'll have time to dive into this further, but reality is that may not happen for a bit due to some of the other larger improvements we've got in flight.

In the meantime you are welcome to use the dry-run script to investigate further. It should be relatively straightforward, just run it within the docker container (see the linked docs), and sprinkle debugger / puts statements through the code as needed to try to track down what's happening.

If you are able to zero in on the problem a bit further, that'd certainly be helpful for whenever we do have time to pick this up...

[eirnym]

Updated the issue to include relevant commit

[eirnym]

I don't know how to run properly docker x86-64 machines on M2 CPU