Open sejli opened 1 year ago
This way, we can separate the addition to build.gradle and a repository-wide application of spotlessApply.
I'm not sure that really helps, and would just leave us temporarily broken.
IMO, we should just push it through with a single commit, since spotlessApply
will reformat the code for us. I personally trust Spotless to reformat the code without affecting behavior (since it's never broken me on OpenSearch core).
I suspect that folks contributing to this repo aren't very opinionated about formatting rules and would accept just using e.g. the formatting rules from OpenSearch core: https://github.com/opensearch-project/OpenSearch/blob/a3baa68b7b014520d257efbb0d4b13f66e134d12/gradle/formatting.gradle#L62
Overview
In light of more PRs coming in recently, I've noticed that there are some instances of code where formatting is slightly off or inconsistent with the rest of the code. A linter has been proposed in the past, but has not been followed through with sufficient research.
Implementations
Taking a look at other backend plugins within the
opensearch-project
, the simplest way to include the samespotlessApply
feature as the core repo is to add it in tobuild.gradle
.performance-analyzer
anomaly-detection
job-scheduler
(job-scheduler
uses aformatting.gradle
file, but this is the same pattern as the previous examples)Trying out the first example and running
./gradlew spotlessApply
,git status
shows many files affected.My proposed course of action is to:
build.gradle
spotlessApply
, then create another PRThis way, we can separate the addition to
build.gradle
and a repository-wide application ofspotlessApply
.