Move gradle-check code to its own scripts and upload codecov

[peterzhuamazon]

Signed-off-by: Peter Zhu [email protected]

Description

Move gradle-check code to its own scripts.
It is not easy to keep updating all the branches with any workflow changes in code.
Therefore, move the gradle check code to its own scripts.
This also attempt to upload codecoverage xml to codecov if gradle check success.

Issues Resolved

opensearch-project/opensearch-build#2193

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• 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.

[peterzhuamazon]

Note: Gradle Check is failing due to core code change, not due to my PR changes here.

[owaiskazi19]

Instead of having dependency on the build repo. Can we do something suggested here: #3717 (comment)?

[peterzhuamazon]

Nope, that workflow have not been maintained for over 3 years and it is in 0.0.1 version.
I will not use that for production purposes.

Thanks.

[peterzhuamazon]

Also that one is for API token not the same as generic webhook, where we can pass a lot of information between github and Jenkins.

I dont see a dependency on opensearch-build is an issue the jenkinsfile is in opensearch-build already.

[owaiskazi19]

Can we have the scripts present in OpenSearch repo? Also, a good practice to mark the conversation resolved by the reviewer can be find here

[peterzhuamazon]

The point to present it in opensearch-build repo is so that you dont need to backport to every single branch whenever there is a tiny change.

Remember you have more than 10+ branches need gradle check.

[peterzhuamazon]

Thanks for raising this issues tho, but I believe this is the best way to get gradle check start running.
We can always improve in later PRs.

Thanks.

[dreamer-89]

@peterzhuamazon : Thanks for your effort in pulling up this change.

Regarding location of gradle script, I think it logically belongs to OpenSearch repository. Once the change is stabilized (green runs on main), we can backport this to remaining branches. Going forward; there wouldn't be work needed for future branches cut from main (or release branches).

@dblock @reta WDYT ?

[reta]

@dreamer-89 that's a good point, I have seen both (central repo for build scripts and replicating build scripts across many branches). I think having build material along each branch is the best option when build scripts are trivial or non-existent (like pure Github actions let say). When build scripts are non-trivial (I think this is our case at least now), keeping them centralized at some place (build repository / library) serves better.

[peterzhuamazon]

Hi @reta @dreamer-89

Yes that is the reason why I keep the script in build repo for now.
All the existing actions on market are either not meeting our needs, or too old without any maintenance.
We can improve this later by either forking one of the existing actions, or write a new one to replace.

Right now, like you suggested, it is best to leave it in build repo for now.

Thanks.