I would prefer sthg that is totally transparent to me and not add one
more step I have to remember. Just to push/run CI to find out I missed
it and rinse and repeat... With the recent fix to checkstyle I am happy
as things stand atm. My 2cts
On 26/6/23 8:43, Jacek Lewandowski wrote:
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
