-
Notifications
You must be signed in to change notification settings - Fork 214
Spotless updates #331
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
Spotless updates #331
Conversation
Signed-off-by: Ryan Nett <[email protected]>
@@ -40,6 +40,32 @@ jobs: | |||
- name: Run lint checks | |||
run: | | |||
mvn compiler:compile -Pdev,jdk11 -B -U -e | |||
check-format: |
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.
Can we do simply like Run link checks
above and add the Run format checks
as a separate step of quick-build
instead of creating a new job?
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.
Oh yeah, I didn't notice those were separate steps. I think it might be helpful to have the output separate though, since the build & tests & lint should be passing before approval, but format should be done after. It's easier (for me at least) to see that w/ fully separate tasks. And I don't know of any way to have multiple check results from the same job.
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.
But if your job fail, you can see pretty easily at which step the failure happened. I really see the format check as the same thing as the lint checks so I think we should replicate how it is done, at least for consistency? Also avoid preparing multiple times these containers makes the quick builder "quicker". Finally, since a mvn install
is done in the quick-build
prior to the checks, it will allow us to validate the format of the generated files as well (which we want, right?)
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.
Yeah, if you open the log and read through. I still think it's easier to see at a glance (i.e. in the emails it sends you, or from the PR list) if it's in a separate job, and they should run in parallel. The difference from the lint checks, imo, is that this is supposed to be done after approval, otherwise I'd make it part of the same job. And that's going to be tricky enough for new contributors (backing out format changes is often hard).
I haven't been formatting the generated code, it's not generated as complaint, so we'd need to essentially do a spotless:apply
as part of generation. It would affect the protobuf stuff too. I can, but it didn't seem like something we really needed.
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 difference from the lint checks, imo, is that this is supposed to be done after approval
That's true! Ok let's try it like this then
@@ -40,6 +40,32 @@ jobs: | |||
- name: Run lint checks | |||
run: | | |||
mvn compiler:compile -Pdev,jdk11 -B -U -e | |||
check-format: |
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 difference from the lint checks, imo, is that this is supposed to be done after approval
That's true! Ok let's try it like this then
Not in this PR (obviously), but we should note somewhere that formatting should be done after PRs are approved. Not sure where the best place for that is though. Add it to the contributors doc, obviously, but it's easy to miss that. It would be extra nice to automatically do it on merge but I'm not sure how to do that. I know the main tensorflow repo has something that runs extra checks once it has some sort of approval. |
We’ll think about it yes, we won’t forget since all badly formatted PRs will fail their checks and it might take long before all files are fixed |
In fact, once all files will be reformatted correctly via these type of PRs, we can reenable that plugin by default and remove the extra job. |
Oh yeah, I just mean so new contributors don't commit format changes before approval, not so much so that we don't forget. |
Yeah but they’ll need to activate explicitly that profile to do so and they won’t probably be aware of it, let see how it goes :) |
As per recent discussions, makes format checks off by default (and changes the name), removes the license header check, and adds a separate CI task to check format on PRs. We should probably note somewhere that formatting should be fixed after approval (in the PR template?).
cc @Craigacp @karllessard