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

Support "allowedFilter" without a baseline file #78

Open
qwert2603 opened this issue Jan 24, 2023 · 2 comments
Open

Support "allowedFilter" without a baseline file #78

qwert2603 opened this issue Jan 24, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@qwert2603
Copy link
Contributor

qwert2603 commented Jan 24, 2023

One of the possible use cases of the dependencyGuard plugin is to restrict particular dependencies between modules of a multi-module project. For example, to restrict a feature-module as a dependency of a core-module in an Android project.

Such use case can easily be done via allowedFilter parameter of the dependencyGuard configuration. dependencyGuard plugin can be applied in the core-module with allowedFilter = { !it.startsWith("feature-") }. But a baseline file will also be created in such case, though it is not needed. For core-module we don't need to guard against dependencies changes, but only against particular dependencies themselves.

From this follows that there may be some configuration of the dependencyGuard plugin, that allows to specify allowedFilter without a baseline file creation.

One possible solution may be adding special function noBaseline(), that can be assigned to baselineMap to explicitly specify, that a baseline file is not needed. (using baselineMap = { null } for that is less explicit)

dependencyGuard {
    configuration("releaseRuntimeClasspath") {
        modules = true
        allowedFilter = { !it.startsWith("feature-") }
        baselineMap = noBaseline()
    }
}

Another possible solution may be adding parameter guardDiff or baselineFile (default to true), that will control whether a baseline file will be created or not. But this solution has drawbacks:

  • such parameter can be messed with parameter baselineMap
  • it's easy to break guarding against dependencies changes by assigning baselineFile = false
dependencyGuard {
    configuration("releaseRuntimeClasspath") {
        modules = true
        allowedFilter = { !it.startsWith("feature-") }
        guardDiff = false
    }
}

IMHO, the first solution is preferred, because it is more explicit.

@kyhule
Copy link

kyhule commented Jan 25, 2023

I've been meaning to create a very similar feature request. Our use case would be to prevent test libraries and SNAPSHOT releases via the allowedFilter without maintaining a baseline. I proposed integrating this plugin but many people had reservations as we have a polyrepo architecture so dependencies are getting bumped in the host application repo with every pull request.

@utzcoz
Copy link

utzcoz commented Mar 2, 2024

I also faced a similar scenario that I/We want to use dependency-guard to guard only specific dependencies, and let other dependencies bumped by automate tools if they don't bump the dependency's version that we want to guard. But current dependency-guard looks like requiring the baseline that contains full list of dependencies. Is it possible to support the feature that this issue proposed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants