-
Notifications
You must be signed in to change notification settings - Fork 22
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
Baseline for needs migration #203
Comments
Hey, thanks for the suggestion. Please what are your thoughts and motivation where would you find this useful? :) |
Let's say we have a project with Instead, I'm proposing a violation baseline where you can record all the existing violations. {
":module-a:impl": [
":module-y:impl"
],
"module-b:impl:": [
":module-y:impl",
],
} This way we can fail the build if new violations are added (ex: |
Thanks for sharing more context :) it is a similar topic to what was discussed at: #157. Using more entries within the Another option I can share is that the plugin can be used on each module, not only at the Basically I'm trying to see the gaps which are truly there and the ones which can be done by current feature set as I try to keep the feature set minimal to keep the plugin lean. :) |
Indeed, it's a very similar issue.
I was able to get a more fine-grained allowed ruleset to work, however it was a bit tricky with some custom logic and then labor intensive to manually write each violation. I think having violation baseline generated by the plugin would have been valuable. |
Hey @Laimiux, sorry for not getting back to you earlier - end of the year was busy. One option I was investigating is to use the error message as the simple way to generate the rules as when there is an error, all violations are printed. E.g.
Though it has to be modified as the format required would be So not ideal, but some start 🤔 Anyway about the whole feature you ask for I feel like I won't be able to get to this soon and probably the preferred solution would be unifying the error message format with the configuration so there is a simple way of copy/paste and use this as the baseline. Thanks a lot for raising the issue in any case :) |
I was able to work around this using a hacky solution, but it's becoming harder to scale this. The hacky solution to enable fine-grained violations requires us to define The API to allow certain violations looks like allowedViolations = [
":a:impl": [
":b:impl",
":c:impl"
],
":b:impl": [
":c:impl"
]
] |
Hey, I commented here. At the end it seems just as a change from You can achieve the same |
The problem is that the library only matches on the alias and not the project path. Allowing |
This is a feature suggestion that could help existing projects that have many violations. Instead of having big aliases such as
NeedsMigration
, I wonder if we could have violation baseline which we can generate (similarly to detekt/lint)The text was updated successfully, but these errors were encountered: