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

Task execution should fail if there are no signatures provided #5

Open
szpak opened this issue Sep 25, 2017 · 2 comments
Open

Task execution should fail if there are no signatures provided #5

szpak opened this issue Sep 25, 2017 · 2 comments

Comments

@szpak
Copy link

szpak commented Sep 25, 2017

On the situation a user forget to put some signatures on the signatures classpath the check success without any warning. It can provide false sense of security.

It's mostly unlikely to have no signatures defined as desired state (there are better ways to ignore task execution). Therefore, I suggest to fail the tasks execution by default in that case and maybe provide an extra property ignoreNoSignatures (or something better named) for corner cases.

@xvik
Copy link
Owner

xvik commented Sep 26, 2017

I understand what you mean and I even thought about this several times, but it's not simple.

The plugin could be used for check and signature build. But check task is always added (as part of the main check) which makes "do nothing" behavior desirable when only signatures build is required. Check task is always assigned because it's impossible to know if it's required in the configuration time (plugin works absolutely the same way as other quality plugins).

Of course, the plugin could be split into two plugins for different use cases, but I don't want to do it now (breaking change, version bump.. aagr).

For me, it would be enough informative if animalsnifferCheck task gets SKIPPED when no signatures declared. I remember that I tried to look this already, but there were some blocking problems. As I understand Gradle 4.2 provides much better api for task outputs definition, which may be useful. But, anyway, it's too early to restrict plugin to gradle 4.2.

Overall, this is not a critical issue (and not even too annoying), so I will postpone it until some major evolution (critical bug, new gradle breaking everything, cool new feature etc.) or just when I have more spare time.

@szpak
Copy link
Author

szpak commented Sep 26, 2017

I see your point. I always try to "break" something in my projects to verify that the new tool/plugin works properly, therefore for me it's also not a big issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants