[Keyvault] Update the autorest.md file to use README.md as an input instead of swagger json file
See original GitHub issueWe should be using README file from the spec repo instead of json as an input-file
in autorest.md because readme.md file has all the configuration. If you want to change the configuration, you can override it in the autorest.md.
For example check require
parameter here, we pass readme.md file as an input.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Update the autorest.md file to use swagger README instead of ...
We should be using swagger README files instead of json in autorest.md. For management plane we are using README for all the SDKs...
Read more >Generating Clients with AutoRest
We'll take this incrementally, working on first how to generate a single file, then how to generate with a configuration file, and keep...
Read more >Recently Active 'autorest' Questions
I'm generating the client by running the following command: autorest --input-file="./Resources/swagger.json" --output-... openapi · autorest.
Read more >Failed to update API in Azure - Microsoft Q&A
I tried to generate the swagger.json file by running the 'dotnet swagger tofile' command. If I run it without the '--serializeasv2' argument the ......
Read more >https://raw.githubusercontent.com/Azure/azure-xpla...
json to be configurable through env var #3552 * Standardize User Agent string in request header (Issue #3565). #3578 * Compute * Fixed...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Per internal, ongoing discussion it seems few languages are using these currently. We should unify across languages as well as services, so this will require some effort to make per-feature, per-version tags (at least going forward) and use them across languages. I doubt the technical work itself will be much (almost definitely not), but making sure we get this all in place across languages will take a bit.
Too many languages have different customizations and, while that is supported, with a push toward Cadl this doesn’t seem worth it given how long it’s been open and undone.