Spotless updates

[rnett]

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

[karllessard]

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?

[rnett]

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.

[karllessard]

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?)

[rnett]

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.

[karllessard]

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

[karllessard]

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

[rnett]

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.

[karllessard]

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

[karllessard]

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.

[rnett]

Oh yeah, I just mean so new contributors don't commit format changes before approval, not so much so that we don't forget.

[karllessard]

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 :)