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. >> >>>> >> >>>> >> >>>> >> >
