add catalog-info for backstage#137
Conversation
rosesyrett
changed the title
|
This should not be merged until #135 is merged. This PR sits on top of it, which is why it has so many changes. |
|
AsyncAPI yaml file has now been added at docs/user/reference/asyncapi.yaml, so please add a reference to this to the cataloginfo file. Also please put your openAPI file in the same folder and update the reference to it accordingly. |
|
Be nice to have this validator for the catalog-info, but I'm happy to add it once this is over the line |
|
Also be good to add to the component>metadata section so that the CI and other stuff is visible in backstage |
Codecov Report
@@ Coverage Diff @@
## main #137 +/- ##
==========================================
+ Coverage 87.39% 87.53% +0.13%
==========================================
Files 40 41 +1
Lines 1079 1091 +12
==========================================
+ Hits 943 955 +12
Misses 136 136
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
… openapi.json into the same location as asyncapi.yaml
rosesyrett
changed the title
| providesApis: | ||
| - message-topics | ||
| - restapi | ||
| - blueskydocument-to-scanmessage |
There was a problem hiding this comment.
I think the ugliness of this (since it's not actually emitting ScanMessages, and ScanMessages are defined elsewhere, and this whole provided API is defined elsewhere) is reason enough to say: now is the time to do #167 and fold it into this change.
There was a problem hiding this comment.
I would prefer to address that in a separate change that also includes updating the AsyncAPI definition to reflect that some of it's functionality is now repaced by the REST API. That will allow us to close this ticket and its associated Jira one and schedule the cleanup activity for next sprint.
There was a problem hiding this comment.
Can this be defined in a workflow instead of in the source code? Is there already a workflow to handle autogeneration of OpenAPI Schemas?
There was a problem hiding this comment.
That would mean we couldn't update the OpenAPI definition without submitting the change to GitHub, which sounds wrong to me; I think it should exist in the repo before GitHub is involved to facilitate testing of the API.
| @@ -0,0 +1,5 @@ | |||
| OpenAPI Specification | |||
There was a problem hiding this comment.
You can actually get sphinx to render the spec in a swagger-like way with a plugin, see example in scanspec: https://github.com/dls-controls/scanspec/blob/master/docs/reference/rest_api.rst
Also, I think we should rethink calling the docs "openapi.rst" and "asyncapi.rst", as that only defines the type, not the purpose, of the API they are documenting.
There was a problem hiding this comment.
Yes, I agree. I do think however that renaming the docs is maybe a separate issue that can tie into #181?
There was a problem hiding this comment.
Gonna have a look at that plugin though.
4 participants
related to #113