added cross validation for CI and versions

[ThyTran1402]

Description

When incrementing an OpenSearch version, three files (Version.java, buildSrc/version.properties, .ci/bwcVersions) must be kept in sync manually. There was no CI check to catch inconsistencies between them, making it easy to introduce drift through unrelated PRs as #2430

• Fixed: adds cross validation CI check that validates the three version sources are mutually consistent on every PR and push.

Related Issues

Resolves #2533

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

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 Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Missing Task The workflow calls ./gradlew validateVersionConsistency, but there is no evidence in this PR that the corresponding Gradle task validateVersionConsistency has been defined anywhere in the build scripts. If this task does not exist, the workflow will always fail. The PR description mentions adding a CI check but does not show the Gradle task implementation. ./gradlew validateVersionConsistency Branch Coverage The workflow only triggers on main, [0-9]+.[0-9]+, and [0-9]+.x branches. Release branches or other naming conventions (e.g., feature/*) are not covered. Consider whether this is intentional or if additional branch patterns should be included. pull_request: branches: - main - '[0-9]+.[0-9]+' - '[0-9]+.x' push: branches: - main - '[0-9]+.[0-9]+' - '[0-9]+.x'

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add no-daemon flag for CI stability The Gradle command lacks the --no-daemon flag, which is recommended for CI environments to avoid daemon-related issues and ensure clean, isolated builds. Without it, Gradle may attempt to reuse or start background daemons that can cause flaky behavior in CI runners. .github/workflows/version-consistency.yml [39-40] run: | - ./gradlew validateVersionConsistency + ./gradlew validateVersionConsistency --no-daemon Suggestion importance[1-10]: 4 __ Why: Adding --no-daemon is a reasonable CI best practice to avoid daemon-related flakiness, but many modern CI setups (including those using cache: gradle) work fine without it. The improvement is minor and not critical.	Low

[github-actions]

❌ Gradle check result for e890b5f: 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?

[ThyTran1402]

Hi @jed326 @peternied

Can someone please review the PR?

Thank you!

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.