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

swagger title and version hardcoded #437

Closed
bamnet opened this issue Jul 18, 2017 · 9 comments
Closed

swagger title and version hardcoded #437

bamnet opened this issue Jul 18, 2017 · 9 comments

Comments

@bamnet
Copy link

bamnet commented Jul 18, 2017

Currently the swagger files generated by protoc-gen-swagger have title and version attributes which aren't very useful -

e.g.

"info": {
    "title": "proto/file.proto",
    "version": "version not set"
  },

It would be great if these values better matched the spec, including a title for the service and some version information.

@bamnet
Copy link
Author

bamnet commented Jul 18, 2017

Two implementation ideas come to mind:

  1. Pass title and version as CLI flags.
  2. Parse values from the proto. The service name in the proto coud map to the swagger title and some clever regexing could extract version info from the http paths /v1/method => "v1".

@erwinvaneyk
Copy link

It might be more consistent with other configuration for particular plugins to add it as options in the proto file: https://developers.google.com/protocol-buffers/docs/proto3#options

@achew22
Copy link
Collaborator

achew22 commented Jul 24, 2017

@erwinvaneyk, I think that would be a great way to approach this. Options defined in the proto would be great. @bamnet, would you like to take that on?

@bamnet
Copy link
Author

bamnet commented Jul 24, 2017

I'm not as familiar with the landscape of plugins using custom options for configs, can you point me to a sample or two in the wild using custom options? I'm curious to see the other use cases for them.

Sticking this in the proto is a much better idea than passing them as CLI flags 😄, but I'm not sure of a simple use case where service couldn't translate to title, and version couldn't be parsed from an http annotation following the style guide. Getting a basic version and service name automagically might be helpful for developers who don't want to do any work to the custom options. I can see options giving developers more control if they're not satisfied with the automatic extraction.

@c4milo
Copy link

c4milo commented Jul 25, 2017

FWIW, I did solve this and other customizations using a Makefile and jq to merge the files. I'm happy to share if anyone is interested.

@AlekSi
Copy link
Contributor

AlekSi commented Aug 1, 2017

Related to #303

@patrickwmcgee
Copy link

@c4milo I'd love your Makefile & jq magic until this gets resolved in the actual tooling :)

@c4milo
Copy link

c4milo commented Aug 3, 2017

@patrickwmcgee, sure, this is what I do in my apis repo: https://gist.github.com/c4milo/01e344c369ed2f9e0253ca168047197d

@achew22
Copy link
Collaborator

achew22 commented Dec 14, 2017

I believe you can do this now, thanks to Ivan. Thanks Ivan!

@achew22 achew22 closed this as completed Dec 14, 2017
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

6 participants