Thank you for a solid write up Maxim. And welcome to Cassandra, it's very positive to see you here.
I whole-heartedly agree with nearly everything you write. Some input and questions inline. > > As you may know, the infrastructure team has disabled public sign-up > to ASF JIRA (the GitHub issues are recommended instead). > I suspect (based on chatter in general, but not on dev@ AFAIK) is to avoid GH issues and stick with jira. The sign-up hurdle we will document on the website: CASSANDRA-18064 > == 1. Make the checkstyle config a single point of truth for the > source code style. == > > The checkstyle is already used and included in the Cassandra project > build lifecycle (ant command line, Jenkins, CircleCI). There is no > need to maintain code style configurations for different types of IDEs > (e.g. IntelliJ inspections configuration) since the checkstyle.xml > file can be directly imported to IDE used by a developer. This is fair > for Intellij Idea, NetBeans, and Eclipse. Big +1 > So, I propose to focus on the checks themselves and checking pull > requests with automation scripts, rather than maintaining these > integrations. The benefits here are avoiding all issues with > maintaining configurations for different IDEs. Another good advantage > of this approach would be the ability to add new checkstyle rules > without touching IDE configuration - and such tickets will be LFH and > easy to commit. > > The actions points here are: > > - create an umbrella JIRA ticket for all checkstyle issues e.g. [8] > (or label checkstyle); > - add checkstyle to GitHub pull requests using GitHub actions (execute > ant command); Instead of custom GHA scripting, please use our existing cassandra-artifact.sh (which should already include all such checks). Something like https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:cassandra:mck/github-actions/3.11 > == 3. Enable pushing backwards build results for both Jenkins and > CircleCI to GitHub pull requests. == > > The goal here is to have a "green checkbox" for those GitHub pull > requests that have corresponding Jenkins/CircleCI runs. According to > the following links, it is completely possible to have those. > > https://github.com/jenkinsci/github-branch-source-plugin > https://circleci.com/docs/enable-checks/ > > Moreover, the GitHub Branch Source Plugin is already enabled for the > Cassandra project [16]. The same seems should work the same way for > CirleCI, but I have faced the infrastructure team comment [17] that > describes admin permissions are required for that, so the question is > still open here. I could dig a bit more once we've agreed on it. > > The actions points here are: > - enable Jenkins integration for GitHub pull requests; > - enable CircleCI integration for GitHub pull requests; Some folk use CircleCI, some use ci-cassandra. The green checkbox idea is great, so long as it's optional. We don't want PRs triggering the runs either (there are other mechanisms for triggering for now). > The actions points here are: > > - initiate a wide survey for user and dev lists, to get to know about > the usages; > - remove those configurations that are not used anymore; > - force migration from Ant to Gradle/Maven; Let's leave this out for now. There's too many unknowns here. If there's an IDE configuration that's broken, no one has reported it for ages, and no one is around to fix it, then I say we should raise the discussion to remove it. The Gradle/Maven migration is a hot one, contribute to that discussion but let's not tangle this work up with it, IMHO. Totally agree that IDE project files should be as light weight as possible. > Summarizing everything proposed above I think it is possible to > simplify adding small contributions easier to the codebase as well as > save a bunch of committer's time. > > So, > WDYT about the things described above? > Should I create a CEP for this? I see no need for a CEP here. An epic and tickets will work. Again, thanks for the input Maxim!
