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

Upgrade Swagger data to OpenAPI 3.1 #1310

Merged
merged 8 commits into from Jun 7, 2023
Merged

Conversation

zecakeh
Copy link
Contributor

@zecakeh zecakeh commented Oct 28, 2022

This is still a rough draft.

What was done to get here:

  1. Ran a custom script that uses swagger2openapi to upgrade to OpenAPI 3.0 in batch, but keeps the comments at the top (so the license).
  2. Made a few edits manually to follow the migration guide between OpenAPI 3.0 and 3.1.
  3. Updated and ran scripts/validator.js on the folders in data/api and fixed any issue that was reported.
  4. The converter merged the server URLs into an array of servers. I edited them to split the URLs into variables so we can access the basePath easily for the other tools.
  5. Built the spec before the upgrade, and then again after the upgrade, and fixed the differences between the HTML files. Most of those needed either:
    • Editing the templates to make them compatible with the new format,
    • Restoring data that was removed by the converter (some examples and fields at the same level as a $ref).
  6. Updated scripts/dump-swagger.py to adapt to the changes in the data and generate valid OpenAPI 3.1 data.
  7. Added scripts/swagger-preview.html to allow to preview the generated API with RapiDoc, and to make sure that it works. Also updated the README to replace instructions for previewing with Swagger UI (which is not compatible with OpenAPI 3.1).

What's left to do:

  • The converter added a lot of unnecessary newlines in the descriptions, they should probably be cleaned up.
  • Most of the JSON examples were converted to YAML. Maybe convert all the examples to YAML? Or revert this to make the diff smaller?
  • 4 files do not pass validation in data/api/server-server:
    • keys_query.yaml and keys_server.yaml: the keyId property in the path cannot be required: false, in the OpenAPI 3.1 spec, all properties in path must be required: true.
    • invites-v1.yaml and invites-v2.yaml: the validator complains that it cannot resolve the reference in the example of the 200 response. It's not true because the same reference is used at another place in the file without any issue, so there must be something wrong with the syntax around the $ref.
  • Check every single file that no data was lost (including comments)

I'll open discussions on the code for feedback for the remaining tasks.

Closes #331.

Signed-off-by: Kévin Commaille zecakeh@tedomum.fr

Preview: https://pr1310--matrix-spec-previews.netlify.app

data/api/application-service/definitions/location.yaml Outdated Show resolved Hide resolved
data/api/application-service/query_room.yaml Outdated Show resolved Hide resolved
data/api/client-server/admin.yaml Show resolved Hide resolved
data/api/server-server/invites-v1.yaml Outdated Show resolved Hide resolved
data/api/server-server/invites-v2.yaml Outdated Show resolved Hide resolved
data/api/server-server/keys_query.yaml Outdated Show resolved Hide resolved
data/api/server-server/keys_server.yaml Outdated Show resolved Hide resolved
@zecakeh zecakeh mentioned this pull request Oct 28, 2022
@richvdh
Copy link
Member

richvdh commented Nov 8, 2022

I'm going to mark this as "ready for review" to gather some feedback. It's likely to get overlooked while it's in draft.

@richvdh richvdh marked this pull request as ready for review November 8, 2022 21:12
@richvdh richvdh requested a review from a team as a code owner November 8, 2022 21:12
@richvdh
Copy link
Member

richvdh commented Nov 8, 2022

@zecakeh thank you so much for picking this up - there is a lot of great work here and I am very excited to see it land!

I've made a few comments in reply to your questions.

Generally, I'd love it if we could find ways to pull out bits of this PR to reduce the size of it. For example:

  • Added scripts/swagger-preview.html to allow to preview the generated API with RapiDoc, and to make sure that it works. Also updated the README to replace instructions for previewing with Swagger UI (which is not compatible with OpenAPI 3.1).

    Given RapiDoc is compatible with both OpenAPI 2 and OpenAPI 3, let's do this now as a separate PR, before we change anything else?

  • If there are changes that we can make to the existing definitions (such as replacing |- with >- for the descriptions) which will make them easier to convert, let's do that?

Another question: How much manual editing did you do? Should we aim to script the changes? It might be easier to review a set of conversion scripts than 167 manually-edited files!

@zecakeh
Copy link
Contributor Author

zecakeh commented Nov 9, 2022

Thanks for the feedback.

  Given RapiDoc is compatible with both OpenAPI 2 and OpenAPI 3, let's do this now as a separate PR, before we change anything else?

Done in #1331.

* If there are changes that we can make to the existing definitions (such as replacing `|-` with `>-` for the descriptions) which will make them easier to convert, let's do that?

Sure, I'll look into it.

Another question: How much manual editing did you do? Should we aim to script the changes? It might be easier to review a set of conversion scripts than 167 manually-edited files!

I think I did more manual editing than necessary, mostly because I didn't know what I was getting into, and what a valid result would look like. I'll look into writing scripts to automate most (or all) of it.

@zecakeh
Copy link
Contributor Author

zecakeh commented Nov 10, 2022

I split the different steps needed for conversion, between automatic and manual steps. I also removed the changes that are not strictly necessary.

With these commits:

  • The definitions pass the validator.js script.
  • The generated spec is unchanged except for the same 4 definitions files that wouldn't pass validation otherwise.

I found out another small thing that could reduce the diff if done in a separate PR: switching the definitions and tools to use x-servers. Then during conversion it would just be a x-servers servers change.

@zecakeh
Copy link
Contributor Author

zecakeh commented Nov 10, 2022

I tried with another validator (namely Redocly CLI) and it complained about a few things.

I trust these changes because most of them are required by swagger-parser when declaring the files as OpenAPI 3.0.0, but it stops complaining for some reason when the version is OpenAPI 3.1.0. They also make sense.

Redocly CLI also complains about $ref in examples which doesn't seem to be actually supported by the OpenAPI spec: it expects either the whole example as a $ref, or the complete content of the example.

@richvdh
Copy link
Member

richvdh commented Nov 15, 2022

Redocly CLI also complains about $ref in examples which doesn't seem to be actually supported by the OpenAPI spec: it expects either the whole example as a $ref, or the complete content of the example.

Ok. As I understand it, there are only a couple of places where this is a problem? If so, let's fix it by just copying the complete content into the right place instead of using $ref. Could you open a separate PR?

Likewise, would you be able to open a separate PR for getting rid of {keyId} on the /keys endpoints?

scripts/package.json Show resolved Hide resolved
@zecakeh
Copy link
Contributor Author

zecakeh commented Nov 17, 2022

Redocly CLI also complains about $ref in examples which doesn't seem to be actually supported by the OpenAPI spec: it expects either the whole example as a $ref, or the complete content of the example.

Ok. As I understand it, there are only a couple of places where this is a problem? If so, let's fix it by just copying the complete content into the right place instead of using $ref. Could you open a separate PR?

Done in #1349.

Likewise, would you be able to open a separate PR for getting rid of {keyId} on the /keys endpoints?

Done in #1350.

@richvdh
Copy link
Member

richvdh commented Dec 20, 2022

@zecakeh it's gone a bit quiet here, so I just wanted to say I'm still very excited about seeing this land. I'm trying to push through MSC3938 so we can fix the /keys endpoints, and I believe @KitsuneRal is working his way through a more comprehensive review on this. Please bear with us!

Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

Starting slow: please see some comments from reviewing application-service/, meanwhile I'm in for CS API (but that will likely be my Christmas reading).

data/api/application-service/protocols.yaml Outdated Show resolved Hide resolved
data/api/application-service/protocols.yaml Show resolved Hide resolved
data/api/application-service/protocols.yaml Show resolved Hide resolved
Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

A few more from the first part of client-server/

data/api/client-server/capabilities.yaml Show resolved Hide resolved
data/api/client-server/content-repo.yaml Outdated Show resolved Hide resolved
data/api/client-server/content-repo.yaml Show resolved Hide resolved
data/api/client-server/content-repo.yaml Show resolved Hide resolved
data/api/client-server/content-repo.yaml Show resolved Hide resolved
Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

Okay, client-server/ done.

I realise that the whole body will probably have to be re-converted from the most recent API definitions, so applying those suggestions now would not be prudent - but at least those can be used to apply changes after (or even before, like adding missing http schemes).

data/api/client-server/create_room.yaml Outdated Show resolved Hide resolved
data/api/client-server/create_room.yaml Outdated Show resolved Hide resolved
data/api/client-server/filter.yaml Show resolved Hide resolved
data/api/client-server/inviting.yaml Outdated Show resolved Hide resolved
Comment on lines -56 to -59
# $ref: "definitions/one_time_keys.yaml"
# XXX: We can't define an actual object here, so we have to hope
# that people will look at the swagger source or can figure it out
# from the other endpoints/example.
Copy link
Member

Choose a reason for hiding this comment

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

AFAIR, this can be reconsidered now that we have OpenAPI v3 expressive powers - namely, definitions/one_time_keys.yaml is written with OpenAPI v3 in mind.

data/api/client-server/sync.yaml Show resolved Hide resolved
data/api/client-server/third_party_membership.yaml Outdated Show resolved Hide resolved
data/api/client-server/third_party_membership.yaml Outdated Show resolved Hide resolved
data/api/client-server/typing.yaml Show resolved Hide resolved
data/api/client-server/wellknown.yaml Show resolved Hide resolved
Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

The rest except server-server is covered. Got a couple of ideas after reviewing the scripts - please find below.

data/api/identity/v2_associations.yaml Show resolved Hide resolved
scripts/package.json Show resolved Hide resolved
scripts/openapi-convert/object-fixes.mjs Outdated Show resolved Hide resolved
scripts/openapi-convert/string-fixes.mjs Outdated Show resolved Hide resolved
scripts/openapi-convert/convert-definitions.mjs Outdated Show resolved Hide resolved
Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

The last piece, server-server/ completed. This one has been more problematic - aside from things I could debug (see the comments), most concerning is that the conversion has apparently lost a few examples. I guess it might be because of some weird example/examples confusion or the wrong level of nesting but didn't dig into this, honestly.

data/api/server-server/backfill.yaml Outdated Show resolved Hide resolved
data/api/server-server/keys_query.yaml Outdated Show resolved Hide resolved
data/api/server-server/invites-v1.yaml Outdated Show resolved Hide resolved
data/api/server-server/invites-v2.yaml Outdated Show resolved Hide resolved
data/api/server-server/joins-v1.yaml Outdated Show resolved Hide resolved
data/api/server-server/transactions.yaml Outdated Show resolved Hide resolved
data/api/server-server/user_devices.yaml Outdated Show resolved Hide resolved
data/api/server-server/user_devices.yaml Outdated Show resolved Hide resolved
@KitsuneRal
Copy link
Member

What I would suggest after figuring out what to do on each item from the laundry lists above:

  • apply preparatory commits where necessary (maybe even take them out to separate PRs, as before); I suspect we got examples defined in the wrong place or form in server-server/, fixing that looks like one case here.
  • re-apply the conversion over the most recent main
  • apply all the manual post-fixes
  • force-push the branch under the same name
  • I review the changes across the force-push (GitHub allows to do that)
  • we plan follow-up fixes if any remain

@zecakeh
Copy link
Contributor Author

zecakeh commented Jan 24, 2023

apply preparatory commits where necessary (maybe even take them out to separate PRs, as before); I suspect we got examples defined in the wrong place or form in server-server/, fixing that looks like one case here.

Thanks for taking the time to review everything, I'll try to open PRs for those in the next days.

@zecakeh
Copy link
Contributor Author

zecakeh commented Feb 26, 2023

So we should be good to re-apply the upgrade after #1454 is merged and we agree on the correct fix for server-server/user_devices.yaml (#1310 (comment)), unless I forgot something else that can be fixed before the upgrade.

@KitsuneRal
Copy link
Member

Those PRs are all merged - we should be good to go?

@zecakeh
Copy link
Contributor Author

zecakeh commented Mar 9, 2023

Upgrade re-done on main.

I have added back all comments and examples that were gone. I checked that it passed two OpenAPI validators (swagger-parser and redocly-cli) and that the generated spec has no unwanted changes.

Before merging this we probably want to revert the commit adding the conversion scripts, but I thought it would be better if they were part of the branch history.

Copy link
Member

@KitsuneRal KitsuneRal left a comment

Choose a reason for hiding this comment

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

Sorry for the delayed review. Things are mostly in order now, save for one place with the user agent string sliced into parts in some weird (and actually not correct) way, and examples being kind-of-but-not-quite JSON now. I suggest we go forward with the currently formatted examples, but please address the first comment. Then (after yet another rebase... sorry for that) it should be good enough for merging.

data/api/client-server/admin.yaml Outdated Show resolved Hide resolved
data/api/client-server/admin.yaml Outdated Show resolved Hide resolved
@zecakeh
Copy link
Contributor Author

zecakeh commented May 8, 2023

Should I wait until #1495 is merged to rebase, to avoid a conflict?

@uhoreg
Copy link
Member

uhoreg commented May 9, 2023

Should I wait until #1495 is merged to rebase, to avoid a conflict?

It has been merged, so should be safe to rebase. 😉

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
@zecakeh
Copy link
Contributor Author

zecakeh commented May 9, 2023

Rebased on latest main.

I was unhappy to leave the examples as is so I wrote a dirty little JS script that converts them back to JSON. Hopefully that reduces the diff.

@KitsuneRal
Copy link
Member

Thanks for your patience, again. I think it is as good as it can be for now. The remaining comments can be addressed later. @matrix-org/spec-core-team, I guess it's quite a good moment to merge this, while Matrix v1.8 is still kind of away and there's still time to iron parts that still stick out?

@zecakeh
Copy link
Contributor Author

zecakeh commented Jun 7, 2023

So I should rebase one last time to resolve the conflicts so it can be merged?

@richvdh
Copy link
Member

richvdh commented Jun 7, 2023

So I should rebase one last time to resolve the conflicts so it can be merged?

yes please - either rebase, or better yet, just merge main into your branch and fix up the conflicts by hand, so the changes since @KitsuneRal's review are easy to see. Once you've done so I will press the merge button.

@KitsuneRal
Copy link
Member

KitsuneRal commented Jun 7, 2023

I'm not sure merging will work here because the PR is effectively generated every time. If there's any new endpoint (and I think there was some over this month) it has to be converted by the script.

Up to the hero to decide though.

@zecakeh
Copy link
Contributor Author

zecakeh commented Jun 7, 2023

I improved the script to be able to run it on a single file at a time so I was able to make a merge commit. Once again I checked that they pass the validation and that the generated Matrix spec doesn't have any changes.

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

🎉

@richvdh richvdh merged commit 45b6aaf into matrix-org:main Jun 7, 2023
10 checks passed
@richvdh
Copy link
Member

richvdh commented Jun 7, 2023

Thank you so so much to @zecakeh for all your hard work on this, and to @KitsuneRal for reviewing it. It's fantastic to finally have this landed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade OpenAPI
4 participants