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

[draft] Use a git submodule to include the OpenSearch.openapi.json file #627

Closed
wants to merge 5 commits into from
Closed

[draft] Use a git submodule to include the OpenSearch.openapi.json file #627

wants to merge 5 commits into from

Conversation

jayaddison
Copy link
Contributor

Description

Instead of using an HTTP(S) request to retrieve the latest main OpenSearch.openapi.json spec from opensearch-api-specification.git, reference it as a git submodule and read the contents from file.

Issues Resolved

Resolves #626.

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.

@dblock
Copy link
Member

dblock commented Dec 11, 2023

I like it! Let's document this in .md file(s), CHANGELOG, etc.

@saimedhi
Copy link
Collaborator

Hello @jayaddison, could you please address the failing tests and implement the requested changes? Let's work towards getting this PR merged.

…on.git

Signed-off-by: James Addison <james@reciperadar.com>
Signed-off-by: James Addison <james@reciperadar.com>
Signed-off-by: James Addison <james@reciperadar.com>
… generation-from-specification

Signed-off-by: James Addison <james@reciperadar.com>
Signed-off-by: James Addison <james@reciperadar.com>
@jayaddison
Copy link
Contributor Author

Thanks for the ping @saimedhi. I'd paused here because I'm not certain that my git submodule proposal (#626) is gaining traction. Even so, it seems reasonable to keep up-to-date, and I see that there are changes going on related to API-change-detection.

Should I merge main and resolve conflicts too?

@dblock
Copy link
Member

dblock commented Mar 13, 2024

@Xtansia had some opinions about this direction, what do you recommend we do with this PR?

@Xtansia
Copy link
Contributor

Xtansia commented Mar 13, 2024

@Xtansia had some opinions about this direction, what do you recommend we do with this PR?

@dblock @jayaddison Since we don't yet have a versioning & release process in place for the specs, I'm not completely against this approach for now as it's easy to change in the future. It's important to keep in mind the current proposal to swap the spec repo away from Smithy and at the same time a decent chance the final one-file "complete" spec will not be checked into Git and instead be released in some other manner.

@dblock
Copy link
Member

dblock commented Mar 14, 2024

I think @Xtansia is saying that we won't have a submodule reference if/when we switch to OpenAPI. Let's see what happens with opensearch-project/opensearch-api-specification#189 before we decide on this?

@saimedhi
Copy link
Collaborator

I think @Xtansia is saying that we won't have a submodule reference if/when we switch to OpenAPI. Let's see what happens with opensearch-project/opensearch-api-specification#189 before we decide on this?

@dblock, @Xtansia: Now that opensearch-project/opensearch-api-specification#189 has been resolved, could you please share your thoughts on this PR?

@dblock
Copy link
Member

dblock commented Apr 19, 2024

The spec is no longer committed to git but published as a release, so let's close it.

@dblock dblock closed this Apr 19, 2024
@jayaddison jayaddison deleted the issue-626/submodule-spec-retrieval branch April 20, 2024 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[PROPOSAL] Use a git submodule to include the OpenSearch.openapi.json file
4 participants