Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Libs(all): bump openapi generator from 5.2.0 to 7.9.0 (#1480)
With the existing generator versions, we've had issues during codegen for certain cases in the svix spec including: - serialization of nullable fields - enum (`oneOf`, `anyOf`) representations Bumping the generators all the way up to the latest version (at time of writing, `7.9.0`) seems to resolve both of these, at least partially. Some refactoring of extant template overrides has been required to "re-seat" our local patches on top of the newer templates. There have also been cases of the generated symbol names using slightly different schemes than in earlier generator versions. The high-level API had to be updated to use the new names. ## Approach Customization to the codegen comes in 2 flavors: - edits to templates. - manual edits where the codegen is checked-in to git and the paths are recorded in an `.openapi-generator-ignore` file. Templates are better because they don't hide the customization as readily, but we've got a mix of these approaches throughout. At a high-level, this change followed the following steps: - replace templates entirely with the version tagged for 7.9.0. - recreate our local patches _on top_ as a single rev. - leave behind any customization made moot by upstream refactors. - try to remove as many manual edits/ignores by migrating into templates where needed or just omitting the change entirely. - add a light/gentle test to check specific behaviors things we had hacks in place for: - nullable containers (ie. Endpoint channels and filter types). - responses with empty bodies. In addition to doing the "upstream merge" on template sources, I also had to sometimes look at the dependencies a lib depends on, upgrading or changing the package manifest, or build tooling. When refering/comparing to the upstream templates: - https://github.com/OpenAPITools/openapi-generator/blob/v7.9.0/modules/openapi-generator/src/main/resources/ (the new generator version tag) - https://github.com/OpenAPITools/openapi-generator/blob/v5.2.0/modules/openapi-generator/src/main/resources/ (the older one) ## Status Each lib came with its own challenges. Some I have higher or lower confidence in. I'll call out the ones that are weaker so reviewers can give more scrutiny. **Ruby**: ~~I wasn't able to get my local ruby setup in a healthy enough state to follow along with the readme instructions for building/testing. This one needs a so-called "kitchen sink" test like I added to the other libs, and may need some dependencies bumped. Normally the dep updates required become known during testing.~~ **Edit:** setting `BUNDLE_PATH=$HOME/.gems` unblocked me. Apparently `bundle install` tries to put stuff on the "system" level by default (i.e. requiring `sudo`, and not really what I wanted anyway). With this, I was able to learn enough Ruby to get a test written, and also verify that the deps are lined up as needed. Ruby seems to be in good shape! **Python**: This was the last lib I worked on, and I ran out of time. The "kitchen sink" test looks good, and we also have a decent set of tests that give me _okay confidence_ but here's where I cut corners. I left the templates, manual edits, dependencies and the rest all as-is in the hopes that the boon of the tests will surface problems that stem from all the surrounding code being updated around this stuff that stays where it is. The tests are passing, so maybe we're good, but we should loop back and try to do proper updates to this one. **C#**: manual edits for nullability were left in place for now. A "kitchen sink" test was written, but has also been reverted because however I wrote it ended up using language features not supported by dotnet 5.0 (which our CI process is targeting). The tests pass locally when I update the solution to target 8.0, so I feel good about the lib generally. I was not able to figure out how to install dotnet 5.0 on my system since it's beyond End of Life. We should look to update our target to a currently supported dotnet like 8.0, at which point we can un-revert the test! **Kotlin**: had to update the version of kotlin we build with, but other than that I think things look good. There's a fixme in the ApiClient template about updating the retry loop to work for 2 flavors of request sending; I'd like to look at that in a follow-up, later. The rest all seemed okay and not very concerning to me. ## Verification The so-called "kitchen sink" tests added to each lib follow a pattern of auto-skipping by default and running only when the env vars `SVIX_TOKEN` and `SVIX_SERVER_URL` are set. The test will then step through creating an app and an endpoint, patching the endpoint, and finally deleting the endpoint. Currently these tests are not setup to run in CI, but they _could be_ if we are able to automate raising the docker-compose stack, generating a valid token, and setting the env vars such that they are available to each "lint" or "test" workflow. For now, these tests have been seen to work locally on my machine, and hopefully yours as well. ## Notes for Reviewers I can offer 2 bits of advice when reviewing this chungus of a diff. 1. I split this into many commits and it may be helpful to review one by one. 2. Many files such as the templates themselves may be easier to read if you "ignore whitespace" (at your discretion). It would be good if someone knowledgeable in Ruby could actually build the package and add a similar "kitchen sink" test before this merges, but I don't know if @svix-gabriel is willing to dive into this rabbit hole with me. Please and thank you, Gabriel! Good luck!
- Loading branch information
