> The context is that we currently have 3 checks in the build: > > - Checkstyle, > - Eclipse-Warnings, > - RAT
And dependency-check (owasp). > I want to discuss whether you are ok with extracting all checks to their > distinct target and not running it automatically with the targets which devs > usually run locally. In particular: > > > "build", "jar", and all "test" targets would not trigger CheckStyle, RAT or > Eclipse-Warnings > A new target "check" would trigger all CheckStyle, RAT, and Eclipse-Warnings > The new "check" target would be run along with the "artifacts" target on > Jenkins-CI, and it as a separate build step in CircleCI +0 I prefer this opt-in over an opt-out approach. It should be separated from `artifacts` too. We would need to encourage engineers to run `ant check` before starting CI and/or requesting review. I'm in favour of the opt-in approach because it keeps it visible. Folks configure flags and it "disappears" forever. Also it's a headache in all the other ant targets where we actually don't want it, e.g. tests. If we go with opt-out i'd like to see one flag that can disable all checks: `-Dchecks.skip` > That could be fixed by running checks in a pre-push Git hook. There are some > benefits of this compared to the current behavior: -1 committing and pushing to a personal branch is often done to save work or for cross-machine or collaboration. We should not gate on checks or compilation here. PRs should fail if checks fail, to give newcomers clear feedback (and to take this nit-picking out of the review process).
