Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lower Java version to 11 for OpenSearch 1.3.0. #981

Merged
merged 1 commit into from
Nov 17, 2021
Merged

Lower Java version to 11 for OpenSearch 1.3.0. #981

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions manifests/1.3.0/opensearch-1.3.0.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,15 @@
schema-version: '1.0'
build:
name: OpenSearch
version: 1.3.0
ci:
image:
name: "opensearchstaging/ci-runner:centos7-x64-arm64-jdkmulti-node10.24.1-cypress6.9.1-20211028"
args: "-e JAVA_HOME=/opt/java/openjdk-11"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this change the integration test environment jdk too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not today. Because we have never run any automation for integration tests currently it would use whatever JAVA_HOME you have on your machine. When we put that into Jenkins, we'll need to decide what to use. Note that it sort of doesn't matter because you're deploying an OpenSearch cluster with the JVM packaged inside OpenSearch, so if we wanted to test OpenSearch with multiple JVMs, you'd need to produce distributions with different versions of the bundled JVM or swap the JVM before starting any test cluster.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note; this is a great example of why I like the integration tests that start up a cluster to be coupled to the build process.. if that is a good enough trade-off is still up for debate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. One way is to have no-jdk distribution and a jdk matrix to run integration test against.

components:
- checks:
- gradle:publish
- gradle:properties:version
name: OpenSearch
ref: 1.x
- name: OpenSearch
ref: '1.x'
repository: https://github.com/opensearch-project/OpenSearch.git
schema-version: '1.0'
checks:
- gradle:publish
- gradle:properties:version