Maxim, I don't think it would work, especially this command:
"ant test -Dno-build=true" would execute the whole pipeline up to the "test" target, skipping only the "build" target. However, none of its dependencies would be missed. In Ant, when a target is skipped due to some property, skipping applies only to that target, but its dependencies are executed as usual. Also, I started this discussion because the commands we execute locally should be short, simple, easily memorable, and self-explanatory. We want everybody to refrain from digging into the build.xml to learn flags. Please correct me if I'm wrong, but I believe this is what most of us do from the terminal: - cleaning, - building jars, - running checks (currently implicitly by building or testing), - running tests of a single method / test-class - generating IDE configuration Everyone has excellent ideas, but those suggestions do not converge into a single solution. That's why I'd like to make that simple change that would reduce flags' use in everyday development. Concretely, can we get an agreement to: - Remove the checkstyle dependency from "jar" and "test" - Create a single "check" target that includes all the checks we expect to pass in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making this task the default. ? thanks, Jacek czw., 6 lip 2023 o 19:55 Jon Meredith <jonmered...@apache.org> napisał(a): > sorry, hit send early. > > ant test is an interesting one as it seems impractical to run all tests > sequentially, but somebody may want to I suppose. > > On Thu, Jul 6, 2023 at 11:53 AM Jon Meredith <jonmered...@apache.org> > wrote: > >> I think the -Dno-blah settings have usability issues. As they look at >> the property name, not the value, you cannot override them or default >> them with ANT_ARGS or by importing to another ant build file. The way >> rat.skip does it seems much better using configured value. >> >> Ideally, I would like an easy/fast configuration to set a default for >> checks that slow up the compilation/test cycle locally to be able to >> iterate quickly compile and deal with javadoc/checkstyle comments when >> they're ready to commit, or opt into them on the commandline when >> needed. >> >> e.g. >> export ANT_ARGS="-Dcheckstyle.default=skip -Djavadoc.default=skip" >> ant # should just compile, no checkstyle/javadoc etc >> ant checkstyle # explicitly requested, run checkstyle >> >> Similarly I'd like to have the option to configure any CI system I run so >> all >> non-execution essential checks run in their own pipeline and fail the >> build if there's a problem, but still run the other test targets despite >> violations. Each builder wasted the time running the checks that only >> need to happen once and you didn't get feedback about your tests that >> could have run. Of course not everybody may want that and the main >> Apache Cassandra CI may only want to run tests for checked commits >> for resource reasons. >> >> Also,as a minor nuisance, if you forget the =true as in the examples, >> ant consumes the next argument as the value, so "ant publish >> -Dno-tests -Dno-checks" would set no-tests=-Dno-checks and run the >> checks you tried to skip anyway. >> >> Back to the proposal, I like the idea of an explicit check target that >> runs all checks, >> I would not personally have the default target run them but think that's >> fine as long >> as you can disable them. >> >> ant test is an interesting one >> >> On Thu, Jul 6, 2023 at 7:30 AM Maxim Muzafarov <mmu...@apache.org> wrote: >> >>> In my humble opinion, it is better to have only one plain and >>> straightforward build pipeline for the whole project, with custom >>> flags used to skip a particular step, than to have multiple pipelines >>> under the ant tool with multiple endpoints accordingly. I mean, all >>> the steps need to be lined up, with each step in the pipeline >>> executing everything that stands before it unless skip flags are >>> specified. Meanwhile, I like your idea of grouping all the checks >>> under the dedicated step (and changing the no-checkstyle flag to >>> no-checks accordingly as Ekaterina mentioned). >>> >>> >>> Let me share a simple example of what I'm talking about with one >>> single endpoint. >>> Let's assume the following step order: >>> >>> init -> _build_java (compile) -> checks -> build -> jar -> test -> >>> artifacts -> publish; >>> >>> So, the use would be: >>> >>> ant jar -Dno-checks >>> ant test -Dno-build >>> ant publish -Dno-tests -Dno-checks >>> >>> >>> I'm not saying what you've proposed is bad, in fact, we're not >>> currently doing the pipeline I'm talking about, but adding an >>> additional endpoint is something we should consider very carefully as >>> it may create some difficulties for Maven/Gradle migration if it ever >>> happens. >>> >>> So, if I'm not mistaken the following you're trying to add a new >>> endpoint to the way how we might build the project: >>> >>> - "ant [check]" = build + all checks (first endpoint) >>> - "ant jar" = build + make jars + no checks (second endpoint) >>> >>> And I would suggest running `ant jar -Dno-checks` instead to achieve >>> the same result assuming the `jar` is still transitively dependent on >>> `checks`. >>> >>> On Thu, 6 Jul 2023 at 14:02, Jacek Lewandowski >>> <lewandowski.ja...@gmail.com> wrote: >>> > >>> > Great discussion, but I feel we still have no conclusion. >>> > >>> > >>> > I fully support automatically setting up IDE(A) to run the necessary >>> stuff automatically in a developer-friendly environment, but let it be >>> continued in a separate thread. >>> > >>> > >>> > I wouldn't say I like flags, especially if they have to be used on a >>> daily basis. The build script help message does not list them when "ant -p" >>> is run. >>> > >>> > >>> > I'm going to make these changes unless it is vetoed: >>> > >>> > "ant [check]" = build + all checks, build everything, and run all the >>> checks; also, this would become the default target if no target is specified >>> > "ant jar" = build + make jars: build all the jars and tests, no checks >>> > All "test" commands = build + make jars + run the tests: build all the >>> jars and tests, run the tests, no checks >>> > >>> > >>> > Therefore, a user who wants to validate their branch before running CI >>> would need to run just "ant" without any args. This way, a newcomer who >>> does not know our build targets will likely run the checks. >>> > >>> > >>> > We still need some flags for skipping specific tasks to optimize for >>> CI, but in general, they would not be required for local development. >>> > >>> > >>> > Flags will also be needed to customize some tasks, but they should be >>> optional for newcomers. In addition, a "help" target could display a list >>> of selected tasks and properties with descriptions. >>> > >>> > >>> > I'd be more than happy if we could conclude the discussion somehow and >>> move forward :) >>> > >>> > >>> > thanks, >>> > >>> > Jacek >>> > >>> > >>> > >>> > czw., 29 cze 2023 o 23:34 Ekaterina Dimitrova <e.dimitr...@gmail.com> >>> napisał(a): >>> >> >>> >> There is a separate thread started and respective ticket for >>> generate-idea-files. >>> >> https://lists.apache.org/thread/o2fdkyv2skvf9ngy9jhpnhvo92qvr17m >>> >> CASSANDRA-18467 >>> >> >>> >> >>> >> On Thu, 29 Jun 2023 at 16:54, Jeremiah Jordan < >>> jeremiah.jor...@gmail.com> wrote: >>> >>> >>> >>> +100 I support making generate-idea-files auto setup everything in >>> IntelliJ for you. If you post a diff, I will test it. >>> >>> >>> >>> On this proposal, I don’t really have an opinion one way or the >>> other about what the default is for local "ant jar”, if its slow I will >>> figure out how to turn it off, if its fast I will leave it on. >>> >>> I do care that CI runs checks, and complains loudly if something is >>> wrong such that it is very easy to tell during review. >>> >>> >>> >>> -Jeremiah >>> >>> >>> >>> On Jun 29, 2023 at 1:44:09 PM, Josh McKenzie <jmcken...@apache.org> >>> wrote: >>> >>>> >>> >>>> In accord I added an opt-out for each hook, and will require such >>> here as well >>> >>>> >>> >>>> On for main branches, off for feature branches seems like it might >>> blanket satisfy this concern? Doesn't fix the "--atomic across 5 branches >>> means style checks and build on hook across those branches" which isn't >>> ideal. I don't think style check failures after push upstream are frequent >>> enough to make the cost/benefit there make sense overall are they? >>> >>>> >>> >>>> Related to this - I have sonarlint, spotbugs, and checkstyle all >>> running inside idea; since pulling those in and tuning the configs a bit I >>> haven't run into a single issue w/our checkstyle build target (go figure). >>> Having the required style checks reflected realtime inside your work >>> environment goes a long way towards making it a more intuitive part of your >>> workflow rather than being an annoying last minute block of your ability to >>> progress that requires circling back into the code. >>> >>>> >>> >>>> From a technical perspective, it looks like adding a reference >>> "externalDependencies.xml" to our ide/idea directory which we copied over >>> during "generate-idea-files" would be sufficient to get idea to pop up >>> prompts to install those extensions if you don't have them when opening the >>> project (theory; haven't tested). >>> >>>> >>> >>>> We'd need to make sure the configuration for each of those was >>> calibrated to our project out of the box of course, but making style >>> considerations a first-class citizen in that way seems a more intuitive and >>> human-centered approach to all this rather than debating nuance of our >>> command-line targets, hooks, and how we present things to people. To >>> Berenguer's point - better to have these be completely invisible to people >>> with their workflows and Just Work (except for when your IDE scolds you for >>> bad behavior w/build errors immediately). >>> >>>> >>> >>>> I still think Flags Are Bad. :) >>> >>>> >>> >>>> On Thu, Jun 29, 2023, at 1:38 PM, Ekaterina Dimitrova wrote: >>> >>>> >>> >>>> Should we just keep a consolidated for all kind of checks no-check >>> flag and get rid of the no-checkstyle one? >>> >>>> >>> >>>> Trading one for one with Josh :-) >>> >>>> >>> >>>> Best regards, >>> >>>> Ekaterina >>> >>>> >>> >>>> On Thu, 29 Jun 2023 at 10:52, Josh McKenzie <jmcken...@apache.org> >>> wrote: >>> >>>> >>> >>>> >>> >>>> I really prefer separate tasks than flags. Flags are not listed in >>> the help message like "ant -p" and are not auto-completed in the terminal. >>> That makes them almost undiscoverable for newcomers. >>> >>>> >>> >>>> Please, no more flags. We are more than flaggy enough right now. >>> >>>> >>> >>>> Having to dig through build.xml to determine how to change things >>> or do things is painful; the more we can avoid this (for oldtimers and >>> newcomers alike!) the better. >>> >>>> >>> >>>> On Thu, Jun 29, 2023, at 8:34 AM, Mick Semb Wever wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Thu, 29 Jun 2023 at 13:30, Jacek Lewandowski < >>> lewandowski.ja...@gmail.com> wrote: >>> >>>> >>> >>>> There is another target called "build", which retrieves >>> dependencies, and then calls "build-project". >>> >>>> >>> >>>> >>> >>>> >>> >>>> Is it intended to be called by a user ? >>> >>>> >>> >>>> If not, please follow the ant style prefixing the target name with >>> an underscore (so that it does not appear in the `ant -projecthelp` list). >>> >>>> >>> >>>> If possible, I agree with Brandon, `build` is the better name to >>> expose to the user. >>> >>>> >>> >>>> >>> >>>> >>> >>
