-
Notifications
You must be signed in to change notification settings - Fork 17
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 CSV format for get_info
and allow including any violation types
#110
Merged
professor
merged 8 commits into
rubyatscale:main
from
oboxodo:support_csv_format_for_get_info
Oct 13, 2023
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
33be05e
Refactor to separate stats-collection from output (no visible change)
oboxodo 7d6ca58
Use data instead of methods to distinguish violation type
oboxodo 490dd31
Use hashes and arrays allow easy support for new types (no visible ch…
oboxodo b876ba6
Add support for reporting packs info in CSV format
oboxodo 8c874fe
Include architecture violations on get_info
oboxodo 7c24364
Allow specifying what types of violations to output on get_info
oboxodo 9f419a5
Allow including a Date in the get_info report (useful for snapshots)
oboxodo 3431f36
Prefer some more code readability over DRYness
oboxodo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find the original code with the 4 puts easier to read and understand. I understand that there's duplication. I would prefer a small amount of duplication over an abstraction layer that makes it harder for new-to-the-code-base developer to understand.
If you agree, that would mean that we don't need these above:
And we could simply the printing below.
Otherwise, I'm happy to merge this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review!
The problem with that is that then we can't easily support new violation types. Or even allow the user to select which ones they want from the CLI.
In my case, I'm currently interested in
architecture
violations and notdependency
norprivacy
for the time being.An intermediate solution would be to have duplicate lines one for inbound and one for outbound, but still loop through a list of violation types. Would you be ok with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about now, @professor? I removed the
directions
anddir_x_types
variables and the looping overdirections
. I can't really remove the looping overtypes
as that's one of the main purposes of this PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update to the PR.
When I look at the original code, I would find something like [1] easier to read than [2]
[1] will allow the user to select which types they want displayed. Maybe I'm missing something else with the change. Thanks again @oboxodo for improving the code with this feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, @professor. Here are my thoughts:
Yes, [1] is more readable than [2]. But [1] is hardcoded to only support
privacy
,dependency
, andarchitecture
. IIRC I've seenvisibility
checks too in packwerk and then that code would need to be changed in order to support that (or any other future check FWIW). [2] has the benefit of not needing to be updated because it supports any checks that could come in the future (as long as they support the same API as the current ones which seems to be the goal).On top of that, you're showing [2] as two separate loops but those loops are there for different reasons. The goal of the first loop is to collect the violations regardless of how they're going to be reported. I introduced that
row
hash as an intermediate format-independent way to collect the data, then there's separate code to interpret that row and convert it into either thecsv
format or thedetail
(original) format.I've actually thought a follow-up PR could make this separation more explicit and then the current method would be left only with the pure data-collection code and then delegate outputting to different methods depending on the selected format.
I'd really like to avoid hardcoding anything related to the violation types. Thanks to this, this was the only required change in order to support
architecture
violations. Addingvisibility
or any other future extension should be as simple as that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for the record... all of that reasoning is in line with the work I did on my first PR to this project in #104 where I also removed some hardcoded call to
dependency?
with a more dynamic check, allowing support for bothprivacy
andarchitecture
.