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 ignoreFailures for checkAccessModifier #176

Closed
sghill opened this issue Dec 29, 2020 · 1 comment
Closed

Support ignoreFailures for checkAccessModifier #176

sghill opened this issue Dec 29, 2020 · 1 comment
Milestone

Comments

@sghill
Copy link

sghill commented Dec 29, 2020

The checkAccessModifier task caught me by surprise. I understand its importance and will make necessary changes, none-the-less it might be worthwhile to consider it as a permissible option that just logs warnings before making it mandatory in the next release. The alternative is to just disable the task temporarily. So, I am good with this RC.

Originally posted by @roguexz in #175 (comment)

There is a VerificationTask in Gradle's api that adds this option. It's worth investigating the interface, but it may be more desirable to add properties to the task class for lazy configuration. That would open the door for configuring by project property org.jenkins-ci.jpi.checkAccessModifier.ignoreFailures=true

Ideally we'd also support Gradle's ability to fail on warnings when that property is set.

@sghill sghill added this to the 0.41.0 milestone Dec 29, 2020
@sghill sghill closed this as completed in 6254b41 Dec 31, 2020
@sghill
Copy link
Author

sghill commented Dec 31, 2020

This is now done. Users can opt into failing the build with this configuration:

tasks.named('checkAccessModifier').configure {
    ignoreFailures.set(false)
}

ignoreFailures will become the default, most likely in v1.0.0. Users who opt-in now will be able to take advantage of Gradle's up-to-date checks. The task is considered up-to-date unless the sources or compileClasspath dependencies change.

I didn't end up implementing the VerificationTask for two reasons:

  1. It declares a non-lazy property as an Input
  2. It's not clear there is much utility for users

The only reason I can come up with for implementing the interface is to be able to disable ignoreFailures for all verification tasks. If there is someone who needs this functionality, feel free to reach out.

I considered implementing a project property, but I don't see an obvious order of precedence between configuring the task directly and project properties. It'd be fairly simple for a user to implement this functionality within a buildscript.

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

No branches or pull requests

1 participant