Move OpenSearch-specific Jenkins file from opensearch-build

[andrross]

These files are entirely related to running CI workflows against this repository. They share nothing else in opensearch-build. They belong in this repository.

Related Issues

Resolves opensearch-project/opensearch-build#6094

Check List

• Functionality includes testing.

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.

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit 03dfe22.

Path	Line	Severity	Description
.ci/jenkins/scripts/gradle-check.sh	67	medium	PAYLOAD_JSON is constructed via unquoted shell variable interpolation without sanitization. Values like pr_title (partially sanitized) and pr_from_sha, pr_owner, etc. are interpolated directly into a JSON string, which could allow JSON injection if those environment variables contain special characters (quotes, backslashes). This could manipulate the payload sent to the Jenkins webhook trigger.
.ci/jenkins/scripts/gradle-check.sh	87	medium	The curl command to the Jenkins webhook uses '--data "$(echo $PAYLOAD_JSON)"' with unquoted variable, and credentials are passed via '--user ${GITHUB_USER}:${GITHUB_TOKEN}' directly in the command line, which may expose credentials in process listings. Additionally, QUEUE_URL derived from the Jenkins response is used directly in subsequent curl calls without validation, potentially allowing SSRF if the Jenkins response were tampered with.

The table above displays the top 10 most important findings.

Total: 2 | Critical: 0 | High: 0 | Medium: 2 | Low: 0

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 24b4f68)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 Security concerns Sensitive information exposure: In .ci/jenkins/scripts/gradle-check.sh, line 106 prints $PAYLOAD_JSON and line 107 prints $JENKINS_REQ to stdout. While PAYLOAD_JSON itself doesn't contain credentials, the Jenkins response (JENKINS_REQ) could contain sensitive internal infrastructure details. Additionally, the GITHUB_TOKEN and TRIGGER_TOKEN are passed as command-line arguments (-p, -t), which may expose them in process listings. Consider using environment variables or secure input methods instead.

✅ No TODO sections

🔀 Multiple PR themes Sub-PR theme: Add OpenSearch-specific Jenkins CI files to core repository Relevant files: .ci/jenkins/scripts/gradle-check.sh .ci/jenkins/gradle-check.jenkinsfile Sub-PR theme: Update GitHub Actions workflow to use local gradle-check script Relevant files: .github/workflows/gradle-check.yml

⚡ Recommended focus areas for review Security Risk The checkout step now hardcodes ref: 'main' instead of using ${{ github.event.pull_request.head.sha }}. For a pull_request_target event, this means the workflow always checks out the base branch (main) rather than the PR's head commit. This could cause the script being executed to not reflect the PR's changes, but more importantly, it removes the ability to test the actual PR code. Verify this is intentional and does not break the PR-triggered flow. ref: 'main' Unquoted Variables Several variables used in command substitutions and echo statements are unquoted (e.g., $PAYLOAD_JSON, $JENKINS_REQ, $QUEUE_URL, $WORKFLOW_URL), which can cause word splitting or globbing issues. These should be quoted consistently. --data "$(echo $PAYLOAD_JSON)"` echo $PAYLOAD_JSON echo $JENKINS_REQ QUEUE_URL=$(echo $JENKINS_REQ | jq --raw-output '.jobs."gradle-check".url') echo QUEUE_URL $QUEUE_URL echo "wait for jenkins to start workflow" && sleep 15 echo "Check if queue exist in Jenkins after triggering" if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then while [ "$RESULT" = "null" ] && [ "$TIMEPASS" -le "$TIMEOUT" ]; do echo "Use queue information to find build number in Jenkins if available" WORKFLOW_URL=$(curl -s -XGET ${JENKINS_URL}/${QUEUE_URL}api/json --user ${GITHUB_USER}:${GITHUB_TOKEN} | jq --raw-output .executable.url) Logic Bug The condition if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is likely incorrect. When QUEUE_URL is empty or null (indicating the trigger failed), the script still enters the polling loop. The intended logic should probably be if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ] to only proceed when a valid queue URL is returned. if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then Hardcoded Branch The parameterized cron schedule hardcodes GIT_REFERENCE=2.19 as a scheduled branch. This will need to be updated manually when the active maintenance branch changes, and there is no mechanism to keep it current. H 6 * * * %GIT_REFERENCE=2.19;AGENT_LABEL=Jenkins-Agent-Ubuntu2404-X64-M58xlarge-Single-Host '''

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 24b4f68

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix incorrect logical operator in queue URL check The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the first condition is true and the block executes even without a valid queue URL. The intent is to proceed only when QUEUE_URL is non-empty and not the string "null". The condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] -if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then +if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically flawed — it will always be true (when QUEUE_URL is empty, the first condition is true; when it's non-empty, the second condition is true unless it equals "null"). The correct intent is to proceed only when QUEUE_URL is non-empty and not "null", requiring && with -n instead.	High
	Restore dynamic ref for checkout step The checkout step was previously using ${{ github.event.pull_request.head.sha }} to check out the PR's code, but it has been changed to always check out main. This means the workflow will always run against the main branch instead of the actual PR code, defeating the purpose of running gradle-check on pull requests. .github/workflows/gradle-check.yml [72] -ref: 'main' +ref: ${{ github.event.pull_request.head.sha || github.sha }} Suggestion importance[1-10]: 8 __ Why: The change from ${{ github.event.pull_request.head.sha }} to hardcoded 'main' means the workflow always checks out main instead of the PR's actual code, which defeats the purpose of running gradle-check on pull requests. However, the PR seems intentional about using main to get the latest script, so the suggestion to use a fallback expression is valid and important.	Medium
General	Validate required environment variables before use The variables pr_from_sha, pr_from_clone_url, pr_to_clone_url, pr_number, post_merge_action, and pr_owner are used but never validated for being non-empty. If these environment variables are not set, the JSON payload will contain empty values, which could cause silent failures or unexpected behavior in Jenkins. Add validation checks for these required environment variables similar to the existing checks for TRIGGER_TOKEN, GITHUB_USER, and GITHUB_TOKEN. .ci/jenkins/scripts/gradle-check.sh [66-67] +for var in pr_from_sha pr_from_clone_url pr_to_clone_url pr_number post_merge_action pr_owner; do + if [ -z "${!var}" ]; then + echo "Error: Environment variable '$var' is required but not set." + exit 1 + fi +done + PR_TITLE_NEW=`echo $pr_title | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]'` PAYLOAD_JSON="{\"pr_from_sha\": \"$pr_from_sha\", \"pr_from_clone_url\": \"$pr_from_clone_url\", \"pr_to_clone_url\": \"$pr_to_clone_url\", \"pr_title\": \"$PR_TITLE_NEW\", \"pr_number\": \"$pr_number\", \"post_merge_action\": \"$post_merge_action\", \"pr_owner\": \"$pr_owner\", \"gradle_check_command\": \"$GRADLE_CHECK_COMMAND\"}" Suggestion importance[1-10]: 5 __ Why: Adding validation for required environment variables like pr_from_sha, pr_from_clone_url, etc. would improve robustness, but these are expected to be set by the calling GitHub Actions workflow context, making this a minor defensive improvement rather than a critical fix.	Low

---

Previous suggestions

Suggestions up to commit 769e6a7

Category	Suggestion	Impact
Possible issue	Fix incorrect logical operator in queue URL check The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the first condition is true and the block executes even though there's no valid queue URL. The intent is to proceed only when QUEUE_URL is non-empty and not the string "null". The condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] -if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then +if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically flawed — it will always be true (if QUEUE_URL is empty, first condition is true; if non-empty, second condition is almost always true). The fix to use [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ] correctly ensures the block only executes when a valid URL exists.	High
	Use correct ref for each trigger event The checkout step was previously using ${{ github.event.pull_request.head.sha }} to check out the PR's code, but it has been changed to always check out main. For a pull_request_target event, this means the script being run will always be from main rather than the PR branch, which could cause issues if the script was modified in the PR. However, hardcoding main also means that for push events, the actual pushed commit's version of the script is not used. Consider using a conditional expression or the appropriate ref for each trigger event. .github/workflows/gradle-check.yml [72] -ref: 'main' +ref: ${{ github.event_name == 'pull_request_target' && 'main' || github.sha }} Suggestion importance[1-10]: 6 __ Why: The change from ${{ github.event.pull_request.head.sha }} to hardcoded 'main' could cause issues for push events where the actual pushed commit's script should be used. The suggestion to use a conditional expression is valid, though the security rationale for using main on pull_request_target events is also legitimate.	Low
Security	Prevent credential exposure via string interpolation The $DOCKER_PASSWORD and $DOCKER_USERNAME are interpolated directly into the shell script string using Groovy string interpolation, which can expose credentials in the Jenkins build log or process list. Use single quotes or pass them as environment variables to avoid credential leakage. .ci/jenkins/gradle-check.jenkinsfile [134] -def dockerLogin = sh(returnStdout: true, script: "set +x && (echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin) || echo docker error").trim() +def dockerLogin = sh(returnStdout: true, script: 'set +x && (echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin) || echo docker error').trim() Suggestion importance[1-10]: 7 __ Why: Using Groovy double-quote string interpolation with $DOCKER_PASSWORD and $DOCKER_USERNAME can expose credentials. Switching to single quotes prevents Groovy interpolation and relies on shell variable expansion instead, which is safer in Jenkins pipelines.	Medium
General	Quote variable to prevent word splitting The variable $pr_title is unquoted, which can cause word splitting and glob expansion issues if the title contains spaces or special characters. Quote the variable to prevent unintended behavior. .ci/jenkins/scripts/gradle-check.sh [66] -PR_TITLE_NEW=`echo $pr_title | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]'` +PR_TITLE_NEW=$(echo "$pr_title" | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]') Suggestion importance[1-10]: 5 __ Why: Unquoted $pr_title can cause word splitting and glob expansion issues. The suggestion to quote the variable and use $() instead of backticks is a valid best practice improvement for shell scripting robustness.	Low

Suggestions up to commit 92c5d8e

Category	Suggestion	Impact
Possible issue	Fix inverted queue URL validation logic The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the block executes (which would cause failures when using it), and if it equals "null" the block is skipped. The intent appears to be to only proceed when QUEUE_URL is non-empty and not the string "null". The condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] - if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then + if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect — it will enter the block even when QUEUE_URL is empty (which would cause failures), and skip it only when QUEUE_URL equals "null". The fix to use [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ] correctly ensures the block only executes when QUEUE_URL is non-empty and valid.	High
	Hardcoded ref ignores push event branch The checkout step was previously using ${{ github.event.pull_request.head.sha }} to check out the PR's code, but it has been changed to always check out main. For a pull_request_target event, this means the script being run will always be from main rather than the PR branch, which may be intentional for security, but it also means changes to the script in a PR won't be tested. However, for a push event trigger, hardcoding main means the script won't reflect the actual pushed branch. Consider using a conditional or the appropriate ref for each trigger event. .github/workflows/gradle-check.yml [72] - ref: 'main' + ref: ${{ github.event_name == 'pull_request_target' && 'main' || github.sha }} Suggestion importance[1-10]: 5 __ Why: The change from ${{ github.event.pull_request.head.sha }} to hardcoded 'main' is intentional for security with pull_request_target events, but the suggestion raises a valid concern about push events. However, the workflow may be designed to always run the script from main for consistency, making this a design choice rather than a clear bug.	Low
General	Quote variable to prevent word splitting The variable $pr_title is unquoted, which can cause word splitting and globbing issues if the title contains spaces or special characters. It should be quoted to prevent unexpected behavior. .ci/jenkins/scripts/gradle-check.sh [66] - PR_TITLE_NEW=`echo $pr_title | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]'` + PR_TITLE_NEW=$(echo "$pr_title" | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]') Suggestion importance[1-10]: 5 __ Why: Unquoted $pr_title can cause word splitting and globbing issues when the title contains spaces or special characters. Quoting it and using $() instead of backticks is a valid improvement for robustness.	Low
	Handle case where job never started If the outer if [ -z "$QUEUE_URL" ] || ... condition is never entered (e.g., QUEUE_URL is empty or "null"), RESULT remains "null" and WORKFLOW_URL is unset, causing the script to silently exit with code 1 without a meaningful error message. Add an explicit check before the final result evaluation to handle the case where the job never started. .ci/jenkins/scripts/gradle-check.sh [152-156] + if [ "$RESULT" = "null" ]; then + echo "Error: Jenkins job never started or QUEUE_URL was invalid." + exit 1 + fi if [ "$RESULT" == "SUCCESS" ] || [ "$RESULT" == "UNSTABLE" ]; then - echo "Get codeCoverage.xml" && curl -SLO ${WORKFLOW_URL}artifact/codeCoverage.xml --user ${GITHUB_USER}:${GITHUB_TOKEN} - else - exit 1 - fi + echo "Get codeCoverage.xml" && curl -SLO ${WORKFLOW_URL}artifact/codeCoverage.xml --user ${GITHUB_USER}:${GITHUB_TOKEN} + else + exit 1 + fi Suggestion importance[1-10]: 4 __ Why: This is a valid defensive check, but note that suggestion 2 (fixing the || to &&) would largely address the root cause. If the queue URL condition is fixed, this additional guard becomes less critical, though still useful for edge cases.	Low

Suggestions up to commit a763274

Category	Suggestion	Impact
Possible issue	Fix incorrect logical operator in queue URL check The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the block executes (which would cause failures when using it), and if it equals "null" the block also executes. The intent is to only proceed when QUEUE_URL is non-empty and not the string "null". The condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] -if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then +if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: This is a critical logic bug. The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] will always be true (since if QUEUE_URL is empty, the first condition is true, and if it's non-empty, the second condition is almost always true). The correct intent is [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ] to only proceed when the URL is valid.	High
	Hardcoded branch may break non-main push triggers The checkout step was previously using ${{ github.event.pull_request.head.sha }} to check out the PR's code, but it has been changed to always check out main. For a pull_request_target event, this means the script being run will always be from main rather than the PR branch, which may be intentional for security, but it also means changes to gradle-check.sh in a PR won't be tested until merged. However, for push events, hardcoding main could cause issues on non-main branches. Consider using a conditional or the appropriate ref for each trigger event. .github/workflows/gradle-check.yml [72] -ref: 'main' +ref: ${{ github.event_name == 'pull_request_target' && 'main' || github.sha }} Suggestion importance[1-10]: 5 __ Why: The suggestion raises a valid concern about hardcoding ref: 'main' for push events on non-main branches. However, the change from ${{ github.event.pull_request.head.sha }} to main appears intentional for security reasons with pull_request_target, and the improved code using a conditional expression is a reasonable alternative worth considering.	Low
Security	Prevent credential exposure via string interpolation The $DOCKER_PASSWORD and $DOCKER_USERNAME are interpolated directly into the shell script string using Groovy string interpolation, which can expose credentials in logs or cause issues with special characters. Use single quotes or pass them as environment variables to avoid credential leakage. .ci/jenkins/gradle-check.jenkinsfile [134] -def dockerLogin = sh(returnStdout: true, script: "set +x && (echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin) || echo docker error").trim() +def dockerLogin = sh(returnStdout: true, script: 'set +x && (echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin) || echo docker error').trim() Suggestion importance[1-10]: 7 __ Why: Using Groovy double-quote string interpolation with $DOCKER_PASSWORD and $DOCKER_USERNAME can expose credentials in logs. Switching to single quotes ensures the variables are resolved by the shell rather than Groovy, preventing potential credential leakage.	Medium
General	Quote variable to prevent word splitting issues The variable $pr_title is not quoted, which can cause word splitting and glob expansion issues if the title contains spaces or special characters. It should be double-quoted to prevent unintended behavior. .ci/jenkins/scripts/gradle-check.sh [66] -PR_TITLE_NEW=`echo $pr_title | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]'` +PR_TITLE_NEW=$(echo "$pr_title" | tr -dc '[:alnum:] ' | tr '[:upper:]' '[:lower:]') Suggestion importance[1-10]: 5 __ Why: The unquoted $pr_title can cause word splitting and glob expansion issues. The suggestion to quote it and use $() instead of backticks is a valid best practice improvement, though the tr command already strips most problematic characters.	Low

Suggestions up to commit 9b755a2

Category	Suggestion	Impact
Possible issue	Incorrect logical operator in queue URL check The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the first condition is true and the block executes even without a valid queue URL. The intent is likely to proceed only when QUEUE_URL is non-empty and not the string "null". The condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] - if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then + if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically flawed — when QUEUE_URL is empty, the first clause is true and the block executes incorrectly. The fix to use [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ] correctly ensures the block only runs when a valid non-empty, non-null URL is present.	High
	Checkout ref ignores PR changes The checkout step was previously using ${{ github.event.pull_request.head.sha }} to check out the PR's code, but it has been changed to always check out main. For a pull_request_target event, this means the script being run will always be from main rather than the PR branch, which may be intentional for security, but it also means the workflow file itself won't reflect PR changes. However, for the script path .ci/jenkins/scripts/gradle-check.sh to exist when running from a PR that introduces it, the checkout must include the PR's changes. Consider using the PR head SHA conditionally or documenting why main is always used. .github/workflows/gradle-check.yml [72] - ref: 'main' + ref: ${{ github.event_name == 'pull_request_target' && github.event.pull_request.head.sha || 'main' }} Suggestion importance[1-10]: 5 __ Why: The change from ${{ github.event.pull_request.head.sha }} to 'main' is likely intentional for security with pull_request_target events, but the suggestion raises a valid concern about whether the new script at .ci/jenkins/scripts/gradle-check.sh will be available. However, since this PR is adding the script to the repo and it will be on main after merge, the security-conscious approach of always using main is reasonable. The conditional expression suggested is a valid alternative but may not align with the PR's security intent.	Low
General	Missing error handling for unstarted jobs If the outer if condition for QUEUE_URL is never entered (e.g., QUEUE_URL is empty or "null"), RESULT remains "null" and WORKFLOW_URL is unset, causing the script to silently exit with code 1 without a meaningful error message. Add an explicit check before the final result evaluation to handle the case where the job never started. .ci/jenkins/scripts/gradle-check.sh [152-156] + if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" = "null" ]; then + echo "Error: Failed to get a valid queue URL from Jenkins. The job may not have been triggered." + exit 1 + fi + if [ "$RESULT" == "SUCCESS" ] || [ "$RESULT" == "UNSTABLE" ]; then - echo "Get codeCoverage.xml" && curl -SLO ${WORKFLOW_URL}artifact/codeCoverage.xml --user ${GITHUB_USER}:${GITHUB_TOKEN} - else - exit 1 - fi + echo "Get codeCoverage.xml" && curl -SLO ${WORKFLOW_URL}artifact/codeCoverage.xml --user ${GITHUB_USER}:${GITHUB_TOKEN} + else + exit 1 + fi Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that if QUEUE_URL is invalid and the outer block is never entered, RESULT stays "null" and the script exits with code 1 without a clear message. However, this issue is largely a consequence of the bug in suggestion 2 — fixing the || to && would already cause the block to be skipped when QUEUE_URL is empty/null, making this additional guard more of a complementary improvement.	Low

Suggestions up to commit 895b0ec

Category	Suggestion	Impact
Possible issue	Fix incorrect logical operator in condition check The condition [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ] is logically incorrect. If QUEUE_URL is empty, the first condition is true and the block executes even without a valid queue URL. The intent is to proceed only when QUEUE_URL is non-empty and not "null", so the condition should use && instead of ||. .ci/jenkins/scripts/gradle-check.sh [114] -if [ -z "$QUEUE_URL" ] || [ "$QUEUE_URL" != "null" ]; then +if [ -n "$QUEUE_URL" ] && [ "$QUEUE_URL" != "null" ]; then Suggestion importance[1-10]: 9 __ Why: The condition uses || which means the block executes even when QUEUE_URL is empty (no valid queue URL). The correct logic should use && with -n to ensure the block only runs when QUEUE_URL is non-empty and not "null". This is a real bug that would cause incorrect behavior.	High
	Fix potential double-slash in URL construction The URL construction ${JENKINS_URL}/${QUEUE_URL}api/json may result in a double slash or malformed URL since QUEUE_URL (from Jenkins) typically already contains a leading slash and trailing slash. This could cause the curl request to fail. Ensure proper URL joining, for example by removing the extra / between the two variables. .ci/jenkins/scripts/gradle-check.sh [117] -WORKFLOW_URL=$(curl -s -XGET ${JENKINS_URL}/${QUEUE_URL}api/json --user ${GITHUB_USER}:${GITHUB_TOKEN} | jq --raw-output .executable.url) +WORKFLOW_URL=$(curl -s -XGET "${JENKINS_URL}${QUEUE_URL}api/json" --user ${GITHUB_USER}:${GITHUB_TOKEN} | jq --raw-output .executable.url) Suggestion importance[1-10]: 7 __ Why: The URL ${JENKINS_URL}/${QUEUE_URL}api/json likely produces a double slash since Jenkins queue URLs typically include a leading slash. Removing the extra / between JENKINS_URL and QUEUE_URL prevents a malformed URL that could cause curl requests to fail.	Medium
General	Use retry logic when fetching final build result After the timeout check, if RUNNING is still "true" the script sets RESULT="TIMEOUT" and skips this line, but if the workflow completes, RESULT is fetched without retries or error handling, unlike the perform_curl_and_process_with_jq function used elsewhere. Consider using the retry function here for consistency and reliability. .ci/jenkins/scripts/gradle-check.sh [139] -RESULT=$(curl -s -XGET ${WORKFLOW_URL}api/json --user ${GITHUB_USER}:${GITHUB_TOKEN} | jq --raw-output .result) +RESULT=$(perform_curl_and_process_with_jq "${WORKFLOW_URL}" ".result" 10) Suggestion importance[1-10]: 5 __ Why: The final RESULT fetch lacks the retry logic used elsewhere via perform_curl_and_process_with_jq, making it less resilient to transient network failures. Using the retry function here improves consistency and reliability.	Low
	Handle docker login failure result The dockerLogin result is captured but never checked or used. If the docker login fails, the script silently continues due to the || echo docker error fallback. This could lead to image pull failures later. At minimum, log the result or check for the error string. .ci/jenkins/gradle-check.jenkinsfile [134] def dockerLogin = sh(returnStdout: true, script: "set +x && (echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin) || echo docker error").trim() +if (dockerLogin.contains("docker error")) { + echo("WARNING: Docker login failed: ${dockerLogin}") +} Suggestion importance[1-10]: 4 __ Why: The dockerLogin result is captured but never checked, so a failed login would silently continue and potentially cause image pull failures later. Adding a check for the error string improves observability and early failure detection.	Low

[github-actions]

✅ Gradle check result for 03dfe22: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.31%. Comparing base (0d4e50a) to head (24b4f68).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21113      +/-   ##
============================================
+ Coverage     73.20%   73.31%   +0.11%     
- Complexity    73244    73383     +139     
============================================
  Files          5910     5910              
  Lines        334421   334421              
  Branches      48207    48207              
============================================
+ Hits         244805   245191     +386     
+ Misses        70001    69613     -388     
- Partials      19615    19617       +2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Persistent review updated to latest commit fb7edc8

[github-actions]

❌ Gradle check result for fb7edc8: 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]

Persistent review updated to latest commit e2170c5

[github-actions]

Persistent review updated to latest commit 895b0ec

[github-actions]

✅ Gradle check result for 895b0ec: SUCCESS

[peterzhuamazon]

Block it until issues have been addressed.

Thanks.

[github-actions]

Persistent review updated to latest commit 9b755a2

[peterzhuamazon]

Thanks.

[github-actions]

Persistent review updated to latest commit a763274

[github-actions]

❌ Gradle check result for a763274:

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]

Persistent review updated to latest commit 92c5d8e

[github-actions]

❌ Gradle check result for 92c5d8e: 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 92c5d8e: 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]

Persistent review updated to latest commit 769e6a7

[github-actions]

❌ Gradle check result for 769e6a7: 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]

Persistent review updated to latest commit 24b4f68

[github-actions]

✅ Gradle check result for 24b4f68: SUCCESS

[opensearch-trigger-bot]

The backport to 2.x failed:

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

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-21113-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a003fda7574ad08d992a3655faeebe70bf3eb04
# Push it to GitHub
git push --set-upstream origin backport/backport-21113-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

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

[opensearch-trigger-bot]

The backport to 2.19 failed:

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

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.19 2.19
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.19
# Create a new branch
git switch --create backport/backport-21113-to-2.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a003fda7574ad08d992a3655faeebe70bf3eb04
# Push it to GitHub
git push --set-upstream origin backport/backport-21113-to-2.19
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.19

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

[opensearch-trigger-bot]

The backport to 3.6 failed:

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

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-3.6 3.6
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-3.6
# Create a new branch
git switch --create backport/backport-21113-to-3.6
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a003fda7574ad08d992a3655faeebe70bf3eb04
# Push it to GitHub
git push --set-upstream origin backport/backport-21113-to-3.6
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-3.6

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

[gaiksaya]

Wondering if we need to add .ci/jenkins to ignore files as well
https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/gradle-check.yml#L29-L32