-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Configure path prefix via processor abstraction #1226
Conversation
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.
Well these checks are just wrong (the scope lint ones)
Will squash merge away noise |
no worries, it's only one allowed option to merge any pull requests here. |
Since it adds a new config option, could you also add a test in the |
|
||
// Process adds the prefix to each path | ||
func (p *PathPrefixer) Process(issues []result.Issue) ([]result.Issue, error) { | ||
if p.prefix != "" { |
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.
The current logic seems fine to me.
Just a note on immutability, I just take a look at existing implementation of processors. Seems like https://github.com/golangci/golangci-lint/blob/master/pkg/result/processors/utils.go#L40 is widely used (this function create a copy of slides).
What do you think ?
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.
Well, it's safe for this to be mutating the passed in slice because, by definition, the processors happen serially, so there's no risk of a race on the mutated memory.
I would guess the transformSlices function exists because it's easy to mess up working with a slice of values -- every value in a range loop is a copy, etc, etc.
As it is, I figured this is a memory-sensitive application and the Issue struct is non-trivial in its size, so I'd avoid the unnecessary copies and alloc.
Without running any sort of measurements, I'm guessing there's a lot of fat around this processor chain's memory usage and shifting to a pattern like that I've used here would cut it down a bunch.
The only civilized option! :) |
@SVilgelm added to I'm impressed with this project's test coverage. 👍 |
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.
Thank you! Looks good to me.
🥳 looking forward to using it :) |
Oh I don't have the ability to merge btw, if that was ambiguous. |
Let's wait a feedback from @sayboras, he also revised 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.
LGTM 👍
Hey, @jwilner — we just merged your PR to
By joining the team, you’ll be able to label issues, review pull requests, and merge approved pull requests. Thanks again! |
It's wierd that test failed in master https://github.com/golangci/golangci-lint/runs/859811449 and another one #1201 @jwilner Do you have any idea or pointer ? |
@sayboras whoa, huh, one of the tests I added!? I'd be happy to look -- but I can't tell which test it is from the output. Can you point me in the right direction? |
So something about the test runner is failing on the command
Isn't the test dir
|
@jwilner thank you, I merged it to unblock the CI |
Meant as an alternative to #1225 which uses the standard processor abstraction
problem
It's often convenient in monorepos to run a tool from a different directory but still report issues relative to the root of the repository.
This is exactly the problem in the github action golangci/golangci-lint-action#31
proposed solution
Add a flag for specifying a path prefix in output. Default behavior remains the same.
Thanks for a great tool!