-
Notifications
You must be signed in to change notification settings - Fork 637
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
SOLR-16880: Add OAS to 'assembleRelease' task #2125
SOLR-16880: Add OAS to 'assembleRelease' task #2125
Conversation
This adds our OAS to the release artifacts gathered by the 'assembleRelease' task in gradle. It produces a checksum for the OAS file and stores the file in a separate 'oas' directory (similar to the 'changes' directory which already exists for Changes.html). One remaining piece here is signing - this commit attempts to produce an '*.asc' signature for the OAS when signing is enabled, but doesn't quite have it working yet.
One TODO remaining, if we choose to go this route, is to produce an "*.asc" signature for the OAS file. The PR currently contains some logic that tries to do this, but it's still not working for whatever reason. Something to work through at some point... |
Alright, worked through the signing issues with some help (Thanks @HoustonPutman !). This should be functional and ready to go, assuming it's the route we want to take. |
solr/api/build.gradle
Outdated
@@ -28,7 +28,7 @@ ext { | |||
jsClientDir = "${buildDir}/generated/js" | |||
pythonClientDir = "${buildDir}/generated/python" | |||
openApiSpecDir = "${buildDir}/generated/openapi" | |||
openApiSpecFile = "${project.openApiSpecDir}/openapi.json" | |||
openApiSpecFile = "${project.openApiSpecDir}/solr-${version}-openapi.json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For JARs, the version is at the end. Maybe we should do similar? Just a thought.
Does anything test this, or must it be manually inspected? Basically, how do we have confidence that this is basically working? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Agree a better name is solr-openapi-x.y.z
. And I'd wish for .yml
which I find easier to read and diff, but that's mainly taste.
Wrt test, the smoke tester would do something obviously.
I've been validating using the Actually, finding the right invocation of
The first command sets up gpg-agent to delegate your password when buildAndPushRelease.py asks for it. It should prompt you for your password and then you're free to go "get some coffee", as the releaseWizard puts it. |
OK, that makes sense. Will make that change later this morning and merge. |
Modifies our 'assembleRelease' gradle task and smoketester to handle a new release artifact: an OpenAPI spec ("OAS") covering Solr's v2 APIs. The spec (along with associated checksum and signature files) are made available under a separate 'openApi' directory, similar to our 'changes' files. --------- Co-authored-by: Houston Putman <houston@apache.org>
This adds our OAS to the release artifacts gathered by the 'assembleRelease' task in gradle. It produces a checksum for the OAS file and stores the file in a separate 'oas' directory (similar to the 'changes' directory which already exists for Changes.html).
One remaining piece here is signing - this commit attempts to produce an '*.asc' signature for the OAS when signing is enabled, but doesn't quite have it working yet.
https://issues.apache.org/jira/browse/SOLR-16880
Description
Solr has, for some time, produced an OpenAPI spec ("OAS") describing its v2 APIs that it uses to (e.g.) generate Solr clients in various languages. But while it uses the file internally, Solr doesn't (yet) expose the file to users who may wish to do similar things.
Solution
This PR proposes that we publish our openapi spec as a release artifact akin to the various Changes.html files that we also put in artifacts.apache.org. It does this by modifying the gradle tasks (esp. 'assembleRelease') in the 'distribution' gradle module.
Tests
Manual testing via the
buildAndPushRelease.py
script and the smoke tester.Checklist
Please review the following and check all that apply:
main
branch../gradlew check
.