Fix flaky test ResourceAwareTasksTests on windows.

[mch2]

Signed-off-by: Marc Handalian [email protected]

Description

Windows registers a cpu tick at a default of ~15ms which is slightly slower than other OSs. In CI and in most local runs the runnables in this test often complete in under that time and return a 0 value from
ThreadMXBean.getThreadCpuTime. To reduce flakiness in this test accept 0 as a value on Windows.

Issues Resolved

closes #5063

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
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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.

[minalsha]

LGTM

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/6369/
• CommitID: 6b4020b
  Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/6371/
• CommitID: 0d57162
  Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/6370/
• CommitID: 0d57162

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: null ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/6372/
• CommitID: 0a342bc
  Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[opensearch-trigger-bot]

The backport to 1.3 failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-1.3 1.3
# Navigate to the new working tree
pushd ../.worktrees/backport-1.3
# Create a new branch
git switch --create backport/backport-5077-to-1.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 cce04110d95e4266047a66fa4dc91e8fcfe0593d
# Push it to GitHub
git push --set-upstream origin backport/backport-5077-to-1.3
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-1.3

Then, create a pull request where the base branch is 1.3 and the compare/head branch is backport/backport-5077-to-1.3.

[opensearch-trigger-bot]

The backport to 1.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-1.x 1.x
# Navigate to the new working tree
pushd ../.worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-5077-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 cce04110d95e4266047a66fa4dc91e8fcfe0593d
# Push it to GitHub
git push --set-upstream origin backport/backport-5077-to-1.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-1.x

Then, create a pull request where the base branch is 1.x and the compare/head branch is backport/backport-5077-to-1.x.

[dblock]

@mch2 care to backport manually?

[mch2]

This PR doesn't need a backport to 1.x/1.3, this test was introduced in 2.x line.