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.

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

Add support to test against multiple versions of OpenSearch #228

Merged
merged 3 commits into from
May 3, 2022

Conversation

VachaShah
Copy link
Collaborator

Description

Adding support to run tests against multiple versions of OpenSearch in the CI. I separated out the compatibility.yml since the matrix was becoming huge in the integration.yml with multiple node js versions.

Issues Resolved

#214

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

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.

@VachaShah VachaShah requested a review from a team as a code owner April 29, 2022 17:19
@rickfreitas
Copy link

Hello, can i already consider this compatibility matrix as truth?
We have a cluster with opensearch 1.2 on aws, and we are developing our client based on @opensearch-project/[email protected], we saw that elasticsearch client version should match the cluster version, but for opensearch we could use opensearch client 1.1 for 1.2 cluster right?

@dblock dblock requested a review from saratvemulapalli May 3, 2022 15:44
@dblock
Copy link
Member

dblock commented May 3, 2022

Hello, can i already consider this compatibility matrix as truth? We have a cluster with opensearch 1.2 on aws, and we are developing our client based on @opensearch-project/[email protected], we saw that elasticsearch client version should match the cluster version, but for opensearch we could use opensearch client 1.1 for 1.2 cluster right?

Correct. Generally, we're following semver and ensuring there's an easy upgrade path that does not require upgrading in lockstep. Please do check out opensearch-project/opensearch-clients#17 and add your comments!

fail-fast: false
matrix:
entry:
- { version: '1.1.0', secured: 'true' }
Copy link
Member

@saratvemulapalli saratvemulapalli May 3, 2022

Choose a reason for hiding this comment

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

May be Im totally off, I see we are replicating few pieces of code (workflows, compatibility etc ) in all client repositories.
Is there a way we can define these in a single place (May be opensearch-clients) which is the source of truth and consume it in all our client repos?

Copy link
Member

Choose a reason for hiding this comment

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

Looks like you found a really nice way to do this in https://github.com/opensearch-project/opensearch-py/pull/163/files @VachaShah - want to update it here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@dblock Updated the workflow matrix.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@saratvemulapalli Do you mean like having a template in opensearch-clients?

Copy link
Member

Choose a reason for hiding this comment

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

I dont know what a template is :/.
I was looking for a single place where common code can live. Lets take compatibility as an example:

  • Defining this in a central place will make it easier when we add new version support.
  • Enforces our CIs to test against new versions.
  • Keeps all clients in sync.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh got it! Yeah we are trying to keep it as consistent as possible across the client repos but I will keep this in mind if we can place common code. My current thought is having a single place might be difficult since the clients can be on different versions with different compatibility, their CIs are written differently etc. But will explore this once the breaking changes are done.

@VachaShah VachaShah merged commit f62a8cd into opensearch-project:main May 3, 2022
@VachaShah VachaShah deleted the test-multiple-versions branch May 3, 2022 22:46
@VachaShah VachaShah added the backport 1.x Backport to 1.x branch label May 11, 2022
opensearch-trigger-bot bot pushed a commit that referenced this pull request May 11, 2022
* Expand test matrix to include multiple versions of OpenSearch

Signed-off-by: Vacha Shah <[email protected]>

* Add a compatibility matrix

Signed-off-by: Vacha Shah <[email protected]>

* Updating the github workflow matrix

Signed-off-by: Vacha Shah <[email protected]>
(cherry picked from commit f62a8cd)
saratvemulapalli pushed a commit that referenced this pull request May 11, 2022
)

* Expand test matrix to include multiple versions of OpenSearch

Signed-off-by: Vacha Shah <[email protected]>

* Add a compatibility matrix

Signed-off-by: Vacha Shah <[email protected]>

* Updating the github workflow matrix

Signed-off-by: Vacha Shah <[email protected]>
(cherry picked from commit f62a8cd)

Co-authored-by: Vacha Shah <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.x Backport to 1.x branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants