> not running it automatically with the targets which devs usually run locally.
The checks tend to have an opt-out, such as -Dno-checkstyle=true… so its really easy to setup your local environment to opt out what you do not care about… I feel we should force people to opt-out rather than opt-in… > On Jun 26, 2023, at 7:47 AM, Jacek Lewandowski <lewandowski.ja...@gmail.com> > wrote: > > That would work as well Brandon, basically what is proposed in > CASSANDRA-18618, that is "check" target, actually needs to build the project > to perform some verifications - I suppose running "ant check" should be > sufficient. > > - - -- --- ----- -------- ------------- > Jacek Lewandowski > > > pon., 26 cze 2023 o 16:01 Brandon Williams <dri...@gmail.com > <mailto:dri...@gmail.com>> napisał(a): >> The "artifacts" task is not quite the same since it builds other things like >> docs, which significantly contributes to longer build time. I don't see why >> we couldn't add a new task that preserves the old behavior though, "fulljar" >> or something like that. >> >> Kind Regards, >> Brandon >> >> >> On Mon, Jun 26, 2023 at 6:12 AM Jacek Lewandowski >> <lewandowski.ja...@gmail.com <mailto:lewandowski.ja...@gmail.com>> wrote: >>> Yes, I've mentioned that there is a property we can set to skip checkstyle. >>> >>> Currently such a goal is "artifacts" which basically validates everything. >>> >>> >>> - - -- --- ----- -------- ------------- >>> Jacek Lewandowski >>> >>> >>> pon., 26 cze 2023 o 13:09 Mike Adamson <madam...@datastax.com >>> <mailto:madam...@datastax.com>> napisał(a): >>>> While I like the idea of this because of added time these checks take, I >>>> was under the impression that checkstyle (at least) can be disabled with a >>>> flag. >>>> >>>> If we did do this, would it make sense to have a "release" or "commit" >>>> target (or some other name) that ran a full build with all checks that can >>>> be used prior to pushing changes? >>>> >>>> On Mon, 26 Jun 2023 at 08:35, Berenguer Blasi <berenguerbl...@gmail.com >>>> <mailto:berenguerbl...@gmail.com>> wrote: >>>>> 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 >>>> >>>> >>>> -- >>>> <https://www.datastax.com/> Mike Adamson >>>> Engineering >>>> >>>> +1 650 389 6000 <tel:16503896000> | datastax.com >>>> <https://www.datastax.com/> >>>> Find DataStax Online: >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> >>>> >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> >>>> <https://twitter.com/DataStax> >>>> <https://www.datastax.com/blog/rss.xml> <https://github.com/datastax> >>>>
