Hi,
The context is that we currently have 3 checks in the build: - Checkstyle, - Eclipse-Warnings, - RAT CheckStyle and RAT are executed with almost every target we run: build, jar, test, test-some, testclasslist, etc.; on the other hand, Eclipse-Warnings is executed automatically only with the artifacts target. Checkstyle currently uses some caching, so subsequent reruns without cleaning the project validate only the modified files. Both CI - Jenkins and Circle forces running all checks. 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 The rationale for that change is: - Running all the checks together would be more consistent, but running all of them automatically with build and test targets could waste time when we develop something locally, frequently rebuilding and running tests. - On the other hand, it would be more consistent if the build did what we want - as a dev, when prototyping, I don't want to be forced to run analysis (and potentially fix issues) whenever I want to build a project or just run a single test. - There are ways to avoid running checks automatically by specifying some build properties. Though, the discussion is about the default behavior - on the flip side, if one wants to run the checks along with the specified target, they could add the "check" target to the command line. The rationale for keeping the checks running automatically with every target is to reduce the likelihood of not running the checks locally before pushing the branch and being surprised by failing CI soon after starting the build. That could be fixed by running checks in a pre-push Git hook. There are some benefits of this compared to the current behavior: - the checks would be run automatically only once - they would be triggered even for those devs who do everything in IDE and do not even touch Ant commands directly Checks can take time; to optimize that, they could be enforced locally to verify only the modified files in the same way as we currently determine the tests to be repeated for CircleCI. Thanks - - -- --- ----- -------- ------------- Jacek Lewandowski
