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

Integrate the dependency-guard Gradle plugin #8866

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MGaetan89
Copy link
Contributor

@MGaetan89 MGaetan89 commented Feb 23, 2024

Fixes #8631

I've applied the plugin to every module of the project, on the runtimeClasspath configuration (for non-Android modules) and releaseRuntimeClasspath (for Android modules).
Let me know if some modules should be ignored, or if you want to run the check with an other configuration.

I've ran the ./gradlew dependencyGuardBaseline command to generate the initial baseline files for each modules.

And I've created a new workflow to run the ./gradlew dependencyGuard on every push/PR.

@MGaetan89 MGaetan89 force-pushed the 8631_dependency_guard_gradle_plugin branch 3 times, most recently from eaed370 to 2bbee10 Compare February 23, 2024 19:42
@utzcoz
Copy link
Member

utzcoz commented Feb 24, 2024

@MGaetan89 We don't need to apply dependency-guard for test modules, as they can use any dependency versions they want. If one test module wants to guard itself dependencies some day, other people can add it manually, and I think it is very quick.

After some days thought after creating the related issue: could we only use dependency-guard to guard some dependencies only like we only guard guava and some AndroidX dependencies only? I also want to dependabot work for other dependencies, and we can merge dependabot PRs directly after CI passed for almost safe dependencies.

@MGaetan89 MGaetan89 force-pushed the 8631_dependency_guard_gradle_plugin branch from 2bbee10 to a3c46f3 Compare February 25, 2024 08:54
The plugin is applied to every module of the project, on the `runtime*Classpath`
@MGaetan89 MGaetan89 force-pushed the 8631_dependency_guard_gradle_plugin branch from a3c46f3 to cc8607c Compare February 25, 2024 08:56
@MGaetan89
Copy link
Contributor Author

@MGaetan89 We don't need to apply dependency-guard for test modules, as they can use any dependency versions they want. If one test module wants to guard itself dependencies some day, other people can add it manually, and I think it is very quick.

Done. Let me know if I should remove it from other modules too.

After some days thought after creating the related issue: could we only use dependency-guard to guard some dependencies only like we only guard guava and some AndroidX dependencies only? I also want to dependabot work for other dependencies, and we can merge dependabot PRs directly after CI passed for almost safe dependencies.

I'll have a look to see what options the plugin provides

@MGaetan89
Copy link
Contributor Author

Based on the full configuration options, I'd say that it is not currently possible to control only specific dependencies.

@MGaetan89
Copy link
Contributor Author

MGaetan89 commented Feb 25, 2024

We can't limit the checks to specific dependencies, but we can ensure that specific dependencies/versions are not included, but adding rule like:

allowedFilter = { dependency ->
    !dependency.startsWith("com.google.guava:guava") || dependency.endsWith("31.1-jre")
}

The plugin will still complain when a dependency is update, but it will show a dedicated error when a forbidden dependency is pulled in.

Forbidden dependency:

> Disallowed Dependencies found in :errorprone for the configuration "runtimeClasspath" 
  "com.google.guava:guava:32.0.1-jre",
  
  These dependencies are included and must be removed based on the configured 'allowedFilter'.

Dependency update:

> Dependencies Changed in :errorprone for configuration runtimeClasspath
  - com.google.guava:guava:31.1-jre
  + com.google.guava:guava:32.0.1-jre
  - com.google.j2objc:j2objc-annotations:1.3
  + com.google.j2objc:j2objc-annotations:2.8
  - org.checkerframework:checker-qual:3.12.0
  + org.checkerframework:checker-qual:3.33.0
  
  If this is intentional, re-baseline using ./gradlew :errorprone:dependencyGuardBaseline
  Or use ./gradlew dependencyGuardBaseline to re-baseline dependencies in entire project.

@utzcoz utzcoz self-requested a review February 26, 2024 09:47
@utzcoz
Copy link
Member

utzcoz commented Feb 26, 2024

We can't limit the checks to specific dependencies, but we can ensure that specific dependencies/versions are not included, but adding rule like:

Can we use filter to affect generated baseline files? If yes, can we refactor the current code to make the management of allowedFilter easily?

@MGaetan89
Copy link
Contributor Author

I've added allowedFilter locally in my branch, and ran ./gradlew dependencyGuardBaseline , but the baseline files were not modified.
So I guess the rules is used only for validation.

@MGaetan89
Copy link
Contributor Author

Maybe it's possible to configure Dependabot to run ./gradlew dependencyGuardBaseline on its PRs. This way, we can easily see all the dependency changes, instead of having the PR fail.
This way the process remains "review + merge", without having to run the command ourselves.

@utzcoz
Copy link
Member

utzcoz commented Mar 2, 2024

@MGaetan89 I want to file an issue for dependency-guard to check whether it's possible to request dependency-guard to support it.

@utzcoz
Copy link
Member

utzcoz commented Mar 2, 2024

Okay, I found an existed issue that can meet our requirement: dropbox/dependency-guard#78.

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.

Try dropbox/dependency-guard to avoid unexpected dependency changes
2 participants