-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Add swagger.yaml and generate a few types from the spec #27117
Conversation
I guess the types could also be generated from a |
2abf33e
to
3cb9d36
Compare
Big 👍 on the proposed change. |
44ef526
to
0c12029
Compare
@mlaventure the generated types are now using normal |
It looks some much cleaner, thanks! They're not go-lint proof, but I see we added them to the skip list, LGTM |
design LGTM |
ping @dnephin can you rebase? Then I think we should be ready to go. We may need to describe the process (i.e. when to generate, integrate into CI etc) |
Generate Volume type from the swagger.yaml Add makefile target for generating the models Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
and rename it to a more appropriate name ImageSummary. Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
generation fixed some comments. Signed-off-by: Daniel Nephin <dnephin@docker.com>
rebased |
Yes, this also needs CI integration. It should work the same way as our vendor check (but it runs much faster). |
LGTM |
looks like we have enough LGTM's and CI is 💚, merging |
Add swagger.yaml and generate a few types from the spec
Related issues: #22931, #5893, docker/engine-api#77
The swagger spec was developed here: https://github.com/bfirsh/docker-api-reference/blob/master/swagger.yaml. That repo include some validation checks which I think we should also include if this PR is merged.
The swagger spec will initially be used:
api/types
Eventually we should also be able to generate
api/server/router/*
and most ofclient/*
from the spec. Most of the code in those packages is very boilerplate, and would be a lot more consistent if it were generated from a spec.