Changes Analysis

Commit SHA: b52b42f
Comparing To SHA: 29e07ed

API Changes

Summary

├─┬Paths
│ └──[➕] path (10499:3)
└─┬Components
  ├──[➕] responses (37720:7)
  └──[➕] schemas (69694:7)

• Total Changes: 3
• Additions: 3

Report

The full API changes report is available at: https://github.com/opensearch-project/opensearch-api-specification/actions/runs/18724508794/artifacts/4356184611

API Coverage

Thanks @jzonthemtn
This test is failing with 503 error.

Is this plugin part of 2.19? If so you don't need a custom plugins/user_behavior_insights folder, add the tests under default.

Is this plugin part of 2.19? If so you don't need a custom plugins/user_behavior_insights folder, add the tests under default.

No, it's not. Just 3.0. Thanks, will update.

Is this plugin part of 2.19? If so you don't need a custom plugins/user_behavior_insights folder, add the tests under default.

No, it's not. Just 3.0. Thanks, will update.

If it's (going to be) installed by default tests should go into default still and have version: >= 3.0. The plugins tests are for those that require custom setup.

Is this plugin part of 2.19? If so you don't need a custom plugins/user_behavior_insights folder, add the tests under default.

No, it's not. Just 3.0. Thanks, will update.

If it's (going to be) installed by default tests should go into default still and have version: >= 3.0. The plugins tests are for those that require custom setup.

@dblock Sorry, I'm not sure I follow. Are you saying I still don't have it quite right?

@dblock Sorry, I'm not sure I follow. Are you saying I still don't have it quite right?

1. The test is in the right place now, but tests/default/user_behavior_insights/initialize.yaml should be tests/default/ubi/initialize.yaml to match the route.
2. The tests run in CI in a big matrix of versions, so you need to make sure the test only runs on 3.0+ since your feature doesn't exist till then by adding version: 3.0. And you'll need to make sure the build of 3.0 used has your feature (and potentially bump the revision in the CI).

There's probably more. I'd start by making sure the tests pass locally for you.

@dblock Sorry, I'm not sure I follow. Are you saying I still don't have it quite right?

1. The test is in the right place now, but tests/default/user_behavior_insights/initialize.yaml should be tests/default/ubi/initialize.yaml to match the route.
2. The tests run in CI in a big matrix of versions, so you need to make sure the test only runs on 3.0+ since your feature doesn't exist till then by adding version: 3.0. And you'll need to make sure the build of 3.0 used has your feature (and potentially bump the revision in the CI).

There's probably more. I'd start by making sure the tests pass locally for you.

Thanks, I think that got me on the right path.

$ npm run test:spec -- --opensearch-url http://localhost:9200 --tests ./tests/default/ubi/

> opensearch_api_tools@1.0.0 test:spec
> ts-node tools/src/tester/test.ts --opensearch-url http://localhost:9200 --tests ./tests/default/ubi/

[WARNING] No credentials provided, did you forget to set OPENSEARCH_PASSWORD or AWS_ACCESS_KEY_ID?
OpenSearch 3.0.0

PASSED  initialize.yaml (tests/default/ubi/initialize.yaml)

Tested 1/600 paths.

Hi team... Curious if this could be reviewed and merged?

Hi team... Curious if this could be reviewed and merged?

Please iterate to green first? Happy to review when all tests are passing.

Hi team... Curious if this could be reviewed and merged?

Please iterate to green first? Happy to review when all tests are passing.

Thanks , I just looked at the list of Test Specs and saw all green, not the summary with the 2 failing, thanks!

@ajleong623 has volunteered to look at this, as he has more recent experience in the API spec world!

@jzonthemtn Could you try rerunning the tests? I cannot look into the logs since they are out of date

Resolved merge conflict in the changelog.

@jzonthemtn awesome. It looks like the workflows aren’t approved. @epugh, could you please approve the workflows?

I don't think I can... Not sure how to ping the current Maintainers.....

Spec Test Coverage Analysis

@jzonthemtn I think I saw that some of the test failed while running against the cluster during your last attempt since one of the components was unused. I can try to reproduce those test on my end tomorrow and why it didn’t work. Additionally, UI do not know if all the APIs were covered based on the spec coverage analysis. I hope that can help, and let me know if you are not okay with that solution or if there is anything else you would like me to do.

Also, @karenyrx would it be okay if you could approve the workflows? I think it was only approved for that one push.

@jzonthemtn I think you should be very close to iterating to green. Is everything okay on your end?

When we get this in, we'll have code generated api clients for all of the new relevance related features!

Unfortunately, the workflows do not seem to be available. I am also looking forward to having the UBI available for the API specs

@karenyrx Is there a way to approve the workflows for all subsequent pushes?

Hi @ajleong623 , unfortunately I do not see that option. I have approved the recent workflow for now manually.
Is there any blocker to running the CI locally before pushing? https://github.com/opensearch-project/opensearch-api-specification/blob/main/TESTING_GUIDE.md#running-spec-tests-locally

@karenyrx I think I can test it in the local run. It is just that I was not sure which tests were failing. Is the code for running the CI checks the same as the code in the .github folder?

I’m hoping this works 🙏

@karenyrx I think there is a decent chance the workflows will since it was tested locally. Would you mind reapproving the workflows?

@karenyrx The pull request should be ready. I think a good handful of customers were looking forward towards using the ubi api in their client. Hopefully it can be merged.

Thank you!!

Thanks everyone involved.

Awesome!