Check changed files before running gradle check

[gaiksaya]

Description

The repository requires the gradle check job status to pass before merging any PR. With path-ignore filter, this status check was skipped. However, GitHub does not resolve this conflict or allows to specify the requirement to be optional. See #13494 still waiting for gradle-check status to be set.
There are multiple discussions on GH community forums https://github.com/orgs/community/discussions/44490 and all of them requires work around as of now. This change adds one more step to gradle-check job to detect the files changed and accordingly decide whether to run the consecutive steps or not. See examples below:

1. Where gradle check runs for change in build.gradle test gaiksaya/OpenSearch#10
2. Gradle check steps are skipped for changes in md file test gaiksaya/OpenSearch#11

I set my fork requirements to mimic gradle check status as required and this satisfies both conditions

Related Issues

Related #4053

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• Public documentation issue/PR created

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.

[peternied]

I insist we are very careful with allowing the bypass of the gradle check.

If there are changes that are blocked because of the missing gradle check results, lets revert the initial update so we have more time to iterate on this change

• [Edit] I've created a PR to revert Revert "Skip running gradle checks on release notes" #13499

[github-actions]

❌ Gradle check result for 6179f01: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 574d718: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for 6179f01: SUCCESS

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.49%. Comparing base (b15cb0c) to head (6179f01).
Report is 307 commits behind head on main.

❗ Current head 6179f01 differs from pull request most recent head 0de7d21

Please upload reports for the commit 0de7d21 to get more accurate results.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #13498      +/-   ##
============================================
+ Coverage     71.42%   71.49%   +0.07%     
- Complexity    59978    61012    +1034     
============================================
  Files          4985     5050      +65     
  Lines        282275   286806    +4531     
  Branches      40946    41552     +606     
============================================
+ Hits         201603   205046    +3443     
- Misses        63999    64848     +849     
- Partials      16673    16912     +239     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I won't block merging but I've got limited availability for follow up. Please iterate to green on the description check and document the CI failures

[gaiksaya]

@kotwanikunal @reta Can you please review this change? Let me know if I need to add more maintainers.
Thanks!

[dblock]

Looks like @gaiksaya did a ton of iterating on this one and all our suggestions have already been tried :) I am ok with this change as is. One of the concerns I do have is that a gradle check will visibly pass even if it did nothing.

Will leave for more comments for now.

[reta]

@gaiksaya @dblock have some thoughts regarding the problem over the weekend, I think the idea is sound but the way we approach it probably not. Primarily, because for some reason, we only focus on Gradle check but the same "skip me" rules apply to other workflows like assemble (and very likely even precommit).

What if we combine changeset detection + Gradle build instead, and just skip most of the tasks if there are no relevant changes?

[dblock]

What if we combine changeset detection + Gradle build instead, and just skip most of the tasks if there are no relevant changes?

Maybe.

I am confused why we needed to do anything special about gradle check in terms of requiring it to pass. Isn't that what any check does by default?

[reta]

I am confused why we needed to do anything special about gradle check in terms of requiring it to pass. Isn't that what any check does by default?

I mean - we don't need to run the whole test suite if only CHANGELOG.md changes, right?

[gaiksaya]

What if we combine changeset detection + Gradle build instead, and just skip most of the tasks if there are no relevant changes?

Maybe.

I am confused why we needed to do anything special about gradle check in terms of requiring it to pass. Isn't that what any check does by default?

Other workflows are not set to mandatory at branch settings. Current settings for this repo that applies to all branches:

[gaiksaya]

@gaiksaya @dblock have some thoughts regarding the problem over the weekend, I think the idea is sound but the way we approach it probably not. Primarily, because for some reason, we only focus on Gradle check but the same "skip me" rules apply to other workflows like assemble (and very likely even precommit).

What if we combine changeset detection + Gradle build instead, and just skip most of the tasks if there are no relevant changes?

I believe main reason would be other workflows are not as flaky and not so time consuming. Gradle check is a whole different story. What you are suggesting does not need a common workflow. Just adding path-ignore in those workflows would work as GH would just skip them and won't wait at PR merge asking for status.
Drawback: Each workflow would have it own list to ignore which I think is fine?

Also, I believe you mean gradle tasks here? just skip most of the tasks That would need to break down the gradle check right?

[reta]

Thanks @gaiksaya

Drawback: Each workflow would have it own list to ignore which I think is fine?

I think the ignore list is per repository, right? The only thing we may need to figure out - what has changed (changeset)

Also, I believe you mean gradle tasks here? just skip most of the tasks That would need to break down the gradle check right?

Correct, more like onlyIf { hasChanges() } condition.

[gaiksaya]

I think the ignore list is per repository, right? The only thing we may need to figure out - what has changed (changeset)

It's per workflow. Example: https://github.com/opensearch-project/OpenSearch/pull/13477/files# and path.ignore

Also, I believe you mean gradle tasks here? just skip most of the tasks That would need to break down the gradle check right?

Correct, more like onlyIf { hasChanges() } condition.

Can this be a part of gradle check breakdown issue?

[gaiksaya]

I added backporting to 2.x label. Any more branches that this PR should be backported to? Changing the required workflow to pass check from gradle-check to check-result

[reta]

I added backporting to 2.x label. Any more branches that this PR should be backported to?

I think 1.x / 1.3 would benefit from that as well, thank you.

[gaiksaya]

I added backporting to 2.x label. Any more branches that this PR should be backported to?

I think 1.x / 1.3 would benefit from that as well, thank you.

Done! Thank you!