feat: autogenerate go SDK example in the codeSample #772
Conversation
| @@ -15,10 +15,14 @@ | |||
| package filter | |||
|
|
|||
| import ( | |||
| "fmt" | |||
There was a problem hiding this comment.
The main changes were in this file. The files under tests were autogenerated.
| @@ -121,6 +125,41 @@ func newAtlasCliCodeSamplesForOperation(op *openapi3.Operation) codeSample { | |||
| } | |||
| } | |||
|
|
|||
| func (f *CodeSampleFilter) newGoSdkCodeSamplesForOperation(op *openapi3.Operation, opMethod string) codeSample { | |||
| version := strings.ReplaceAll(apiVersion(f.metadata.targetVersion), "-", "") + "001" | |||
There was a problem hiding this comment.
This field represents the SDK version. The value is formatted as YYYY-MM-DD-001, where 001 indicates the first SDK release for that API version. The last three digits are incremented for subsequent releases, but 001 will always be available as the initial version for each API version.
There was a problem hiding this comment.
A bit curious on how this version stays in sync with the latest SDK version:
- Is this reference to the SDK version always being published before SDK?
- Or there is a mechanism for reading the latest SDK version?
There was a problem hiding this comment.
No, neither of those options apply. I generate the SDK version by combining the API version in the format YYYY-DD.MM with 001 as the suffix, which represents the first release for any new API version and is always present. Subsequent releases for the same API version will follow the format YYYY-DD.MM-002, YYYY-DD.MM-003, and so on, but the example will always use the initial 001 release.
If I merge this, I will then create a ticket to improve this to check for the release in the sdk repo but I don't think is critical for the initial example since the 001 is always present.
Proposed changes
This PR adds autogenerated example of the GO SDK in the openapi specification.
You can preview how the documentation will look using this bump.sh link
Redocly: