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

[rust-server] allow @metaswitch to stop maintaining a fork of swagger-codegen #7600

Open
8 of 17 tasks
bjgill opened this issue Feb 6, 2018 · 0 comments
Open
8 of 17 tasks

Comments

@bjgill
Copy link
Contributor

bjgill commented Feb 6, 2018

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.

Any thoughts (@frol @farcaller @wing328)? Do the proposed set of changes seem sensible?

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

No branches or pull requests

1 participant