You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLDR: we'd like to make some changes to testing/CI for rust-server (and maybe fiddle with htmlDocs2 as well?) to allow us to kill off a private fork we're currently maintaining.
Description
At @Metaswitch, we originally created the rust-server generator (see #6613). Since then, we've been contributing new features. Unfortunately, we're starting to discover that the cost of contributing upstream and syncing changes back is getting quite painful.
The problem is that we worked on the rust-server generator for quite a while in a private fork running on a self-hosted GitLab instance. This has meant that our fork has diverged somewhat from upstream, which makes syncing changes back and forth quite painful.
In order to reduce this current burden, I'd quite like to investigate removing the differences that make our fork different. That way, we can develop directly against this project (rather than our fork), and thus get features/fixes contributed faster.
Our current list of differences is:
We use GitLab CI. As such, our fork has a .gitlab-ci.yml file that builds swagger-codegen and then generates and tests the rust-server sample.
We've expanded petstore-with-fake-endpoints-models-for-testing.yaml significantly, adding endpoints to test XML/plaintext/form data/UUIDs/security/securityDefinitions
We've made some changes to the htmlDocs2. Some of these are general improvements that I think we've just not yet got merged. However, some of these are Rust-specific (e.g. adding Rust examples to the generated API docs).
Suggest a fix/enhancement
I think we then probably want to do the following pieces of work:
Add testing for rust-server to the current maven system, and ensure that they get run by travis. Importantly, this should include verifying that the sample is up to date. This will ensure that rust-server can't get silently broken in future.
Add a new petstore template containing all the features rust-server supports - petstore-rust-server.yaml, perhaps? The rust-server testing will use this. We can then use this template to add testing for new rust-server features without breaking tests for the other generators.
Most of the docs differences are straightforward improvements that can get merged across:
Bugfixes to cope with schemas with funny chars etc., including: fixes to vendor extension handling, non-JSON-valid model names, duplicate nicknames
Render scope information (inexplicably omitted)
Fix broken support for "anyOf"
Add support for "readOnly" and "x-nullable"
Improve formatting of: app description, response descriptions, font loading (the font isn't changed, it's just loaded in a different way)
We've also extended htmlDocs2 to add a tab with rust-server examples. It might be possible to get this in if we add an option to control whether this is shown (which defaults to 'off').
Merge across our current backlog of features/fixes:
Hyper 11 support - currently blocking the rest, but expected to land shortly.
Support for URL-encoded form fields
UUID support
Fixes to XML support
Changes to path handling (I believe the only changes are performance improvements)
Split the rust-server template files in a clearer way
Some support for generating rust-server examples, including nice formatting
Once that's done, we should be in a position to be able to drop our current fork and develop directly against swagger-api/swagger-codegen without the current amount of git history juggling we're doing in our fork. This should mean that we can contribute with less friction, and will notice sooner if a change to swagger-api/swagger-codegen breaks our usage.
TLDR: we'd like to make some changes to testing/CI for
rust-server
(and maybe fiddle withhtmlDocs2
as well?) to allow us to kill off a private fork we're currently maintaining.Description
At @Metaswitch, we originally created the
rust-server
generator (see #6613). Since then, we've been contributing new features. Unfortunately, we're starting to discover that the cost of contributing upstream and syncing changes back is getting quite painful.The problem is that we worked on the
rust-server
generator for quite a while in a private fork running on a self-hosted GitLab instance. This has meant that our fork has diverged somewhat from upstream, which makes syncing changes back and forth quite painful.In order to reduce this current burden, I'd quite like to investigate removing the differences that make our fork different. That way, we can develop directly against this project (rather than our fork), and thus get features/fixes contributed faster.
Our current list of differences is:
.gitlab-ci.yml
file that builds swagger-codegen and then generates and tests therust-server
sample.petstore-with-fake-endpoints-models-for-testing.yaml
significantly, adding endpoints to test XML/plaintext/form data/UUIDs/security/securityDefinitions
htmlDocs2
. Some of these are general improvements that I think we've just not yet got merged. However, some of these are Rust-specific (e.g. adding Rust examples to the generated API docs).Suggest a fix/enhancement
I think we then probably want to do the following pieces of work:
rust-server
to the current maven system, and ensure that they get run by travis. Importantly, this should include verifying that the sample is up to date. This will ensure thatrust-server
can't get silently broken in future.rust-server
supports -petstore-rust-server.yaml
, perhaps? Therust-server
testing will use this. We can then use this template to add testing for newrust-server
features without breaking tests for the other generators.htmlDocs2
to add a tab withrust-server
examples. It might be possible to get this in if we add an option to control whether this is shown (which defaults to 'off').rust-server
template files in a clearer wayrust-server
examples, including nice formattingOnce that's done, we should be in a position to be able to drop our current fork and develop directly against swagger-api/swagger-codegen without the current amount of git history juggling we're doing in our fork. This should mean that we can contribute with less friction, and will notice sooner if a change to swagger-api/swagger-codegen breaks our usage.
Any thoughts (@frol @farcaller @wing328)? Do the proposed set of changes seem sensible?
The text was updated successfully, but these errors were encountered: