-
Notifications
You must be signed in to change notification settings - Fork 461
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
Don't reuse BufStep args across invocations #1976
Conversation
} | ||
List<String> args = List.of(exeAbsPath, "format", file.getAbsolutePath()); |
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.
What about just args.set(2, file.getAbsolutePath()
? I think exe.confirmVersionAndGetAbsolutePath();
is fairly expensive, and I don't think we need to call it for every invocation.
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 refactored to only call confirmVersionAndGetAbsolutePath
once - did you see 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.
Good call, looks nice. Sorry for slow turnaround.
} | ||
List<String> args = List.of(exeAbsPath, "format", file.getAbsolutePath()); |
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.
Good call, looks nice. Sorry for slow turnaround.
Published in |
#1779 introduced a regression where the same args will be reused across all invocations to Buf, resulting in Spotless returning garbage for every file except the first during a lint run.
I'm actually not sure what the best way to test this is. Is there a test harness or template that can check multiple files in one plugin run? I should be able to add a failing test that this PR fixes that way.
Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.
Please make sure that your PR allows edits from maintainers. Sometimes its faster for us to just fix something than it is to describe how to fix it.
After creating the PR, please add a commit that adds a bullet-point under the
[Unreleased]
section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:If your change only affects a build plugin, and not the lib, then you only need to update the
plugin-foo/CHANGES.md
for that plugin.If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update
CHANGES.md
for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.This makes it easier for the maintainers to quickly release your changes :)