Our goal is to create automation for generative SDKs beginning with Go and .NET that encompass all of GitHub's product offerings: GitHub.com, Enterprise Server, and Enterprise Cloud specifications.
Generated SDKs should...
- Abstract API implementations providing easy developer experience
- Enable users to easily make use of recommended auth patterns
- Include client-side rate-limiting to make workflow execution more reliable
- Offer complete coverage of the REST API enabling more workflows
- Be an intuitive and discoverable developer experience
- Cover all supported versions of both GHES and Proxima
- Follow the deprecation policies of the GItHub API version at which they are targeted
- Follow a consistent naming scheme
- Have a patching plan for changes to the SDK outside of normal API specification updates (e.g. in case of necessary security updates or backports)
- Work well with our versioning needs
- Be reasonable to manage and maintain by the SDK team and our awesome contributors
- Make the default use case simple to use, understand, and easily differentiated at a glance from the base generative SDK offering
Use the generator to propagate language SDKs, storing the core implementation for each language in the generator itself
These changes represent the product of code generated from GitHub's OpenAPI definitions via Mirosoft Kiota.
- OpenAPI changes are detected from each API representation
- Generator creates the SDKs and ships them to their respective language repos (i.e. dotnet-sdk, go-sdk) and PRs against main
- Packages are manually created and tagged appropriately
These changes represent the "core" aspects of each SDK. These resources consist of middleware, authentication, request and client factories, and other code that is not generated using Kiota. Often, this source is handwritten once, copied to the individual languages' and platforms' staging directories, and then propagated when generating the SDKs for a given GitHub platform.
- Feature is added to all language versions of the SDK in the generator
- PRs are created for all language / platform combinations
- All updates are tagged and shipped
- If we are considering backporting the feature then we will cherry pick and multiply it x the number of supported GHES versions.
These changes represent any external resources or libraries used by the SDKs. In general, the intention is to keep the utilization of external libraries to a minimum to reduce deviations in the source across languanges. This also helps the developer experience of SDKs remain consistent across languages and platforms.
- Dependency is updated for a given language in the GENERATOR for core
- Note: Dependencies for Generated code (i.e. Kiota) will get updated when generation happens
- A Dependency PR is created in each language/platform repo - this is done via dependabot for all workflows and source alike.
- All updates are shipped - tags created (no backport on dependencies unless critical / security issues)
- For one language this means that code is changed in the GENERATOR only.
- If backporting is necessary, a cherry pick in the SDK repos will be required.
- Respect the language idioms
- Use GitHub and community aware monikers and domain language
- SDK = Software Development Kit
- GHES = GitHub Enterprise Server
- Owner.Brand.Platform
- Owner.Brand.Platform.Version
- GitHub.Octokit.SDK
- GitHub.Octokit.GHEC.SDK
- GitHub.Octokit.GHES.SDK.3.10
- GitHub.Octokit.GHES.SDK.3.11
- com.GitHub.Octokit.SDK
- com.GitHub.Octokit.GHES.SDK.3.12
- com.GitHub.Octokit.GHEC.SDK
- github_octokit_sdk
- github_octokit_ghec_sdk
- github_octokit_ghes_sdk_3_12
- Languange.Platform
- go-sdk
- go-sdk-enterprise-server
- go-sdk-enterprise-cloud
- dotnet-sdk
- dotnet-sdk-enterprise-server
- dotnet-sdk-enterprise-cloud