Update non java files

[stephen-crawford]

Description

Updates the code style for everything that is not a java file.

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

Merging #2812 (c469b69) into main (9be79bd) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #2812   +/-   ##
=========================================
  Coverage     61.48%   61.48%           
- Complexity     3401     3402    +1     
=========================================
  Files           266      266           
  Lines         18865    18865           
  Branches       3302     3302           
=========================================
+ Hits          11599    11600    +1     
  Misses         5669     5669           
+ Partials       1597     1596    -1     

see 1 file with indirect coverage changes

[reta]

@scrawfor99 👏 looks pretty good, this is the same rules as for OpenSearch core, right?

[cwperks]

@reta I think this was taken from job-scheduler but it looks very similar to core to me:

• JS: https://github.com/opensearch-project/job-scheduler/blob/main/gradle/formatting.gradle
• core: https://github.com/opensearch-project/OpenSearch/blob/main/gradle/formatting.gradle

[stephen-crawford]

@reta, I checked with core and job scheduler and they are identical. So I just took the one from job scheduler since Craig had already added the changes into a branch of his own.

[cwperks]

@scrawfor99 Please open up a manual backport of this change to 2.x.

[stephen-crawford]

@scrawfor99 Please open up a manual backport of this change to 2.x.

I was just gonna backport the style changes manually once everything is approved if that is okay. Basically, I am intentionally splitting the changes so they can be reviewed but for the backport we can just run the new workflow to backport.

[cwperks]

@scrawfor99 There may be some challenges in backporting other PRs if its in a state where there are formatting changes on main that are not in the 2.x branch. I think it may make sense to backport these individually or do one big PR with all formatting changes.

[stephen-crawford]

Hi @cwperks, the reason the formatting changes are split like this is to try and make reviewing the changes feasible. Basically, there are too many changes to be reviewed altogether so it is easier to tell how things are changing by moving piece by piece.

The issue with backporting each individual PR is that we are not actually backporting a code change but just an updated format guideline. What we would want to backport is just the build.gradle change not the actual code changes resulting from the the updated formatting themselves.

I am not sure how to do that so I am hoping we can instead just update the format of the entirety of 2.x once we have all accepted the changes as appropriate.

Does that make sense?