feat!: Add OIDC authentication support to PrivateRegistries#4159
feat!: Add OIDC authentication support to PrivateRegistries#4159mkushakov wants to merge 10 commits intogoogle:masterfrom
PrivateRegistries#4159Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
PrivateRegistries
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4159 +/- ##
==========================================
- Coverage 93.70% 93.70% -0.01%
==========================================
Files 210 210
Lines 19692 19688 -4
==========================================
- Hits 18453 18449 -4
Misses 1045 1045
Partials 194 194 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
PrivateRegistriesPrivateRegistries
gmlewis
left a comment
There was a problem hiding this comment.
Thank you, @mkushakov!
This is the first GitHub v3 API version breaking change using their new "calendar-versioning" mechanism. As a result, we need to make some more changes in this PR.
According to our README.md:
### Calendar Versioning ###
As of 2022-11-28, GitHub has announced (broken link)
that they are starting to version their v3 API based on "calendar-versioning".
In practice, our goal is to make per-method version overrides (at
least in the core library) rare and temporary.
Our understanding of the GitHub docs is that they will be revving the
entire API to each new date-based version, even if only a few methods
have breaking changes. Other methods will accept the new version with
their existing functionality. So when a new date-based version of the
GitHub API is released, we (the repo maintainers) plan to:
* update each method that had breaking changes, overriding their
per-method API version header. This may happen in one or multiple
commits and PRs, and is all done in the main branch.
* once all of the methods with breaking changes have been updated,
have a final commit that bumps the default API version, and remove
all of the per-method overrides. That would now get a major version
bump when the next go-github release is made.
So we need to override the per-method API version header in this PR according to the blog post, and I'm discovering that the blog post link is now broken.
The new link is:
https://github.blog/developer-skills/github/to-infinity-and-beyond-enabling-the-future-of-githubs-rest-api-with-api-versioning/
According to the blog post, the following header needs to be added to the updated endpoint:
X-GitHub-Api-Version: 2026-03-10
So this endpoint needs to add:
req.Header.Set(headerAPIVersion, "2026-03-10")
c4bdd0e to
b15fc0c
Compare
da81ba9 to
a84603b
Compare
| input := &CreateOrganizationPrivateRegistry{ | ||
| RegistryType: "maven_repository", | ||
| RegistryType: PrivateRegistryTypeMavenRepository, | ||
| URL: "https://maven.pkg.github.com/OWNER/REPOSITORY", |
There was a problem hiding this comment.
@gmlewis Should we also change this URL? I ignore that in #3948 because it has
github.com
Yes, please change this URL to example.com for consistency with the rest of this repo, @mkushakov.
Thank you!
There was a problem hiding this comment.
let me know if you want me to replace it as part of my PR as well
There was a problem hiding this comment.
let me know if you want me to replace it as part of my PR as well
Yes, please do that in this PR.
Thank you 🙂
Thank you, @mkushakov! That does make sense. However, I like to keep track of all breaking changes as we move through the release cycles for those people who are following all the changes as they happen, so let's leave this labeled as a breaking change... at the very least, it will alert those who worked on |
…e registry models
…ing private registries
…s and update accessors
… for AWS and JFrog OIDC provider
b864ebc to
c1c83da
Compare
There was a problem hiding this comment.
We need to somehow update the generated docs for all changed endpoints (2026-03-10 instead of 2022-11-28):
// GitHub API docs: https://docs.github.com/rest/private-registries/organization-configurations?apiVersion=2026-03-10#list-private-registries-for-an-organizationTake a look at the tools/metadata/metadata.go.
There was a problem hiding this comment.
good catch, i have changed tools/metadata/metadata.go to preserve an existing api version if set, and use default 2022-11-28 if not set on resource 7179334
…Registry to use example.com
…rivate registries
|
We try to keep the yaml updates in separate, focused PRs, so I will work on that later today and we can merge that change into this PR to also keep this one focused. |
BREAKING CHANGE:
PrivateRegistriesServiceis updated to API version2026-03-10with struct and response changes.Update the
PrivateRegistriesServiceto align with the GitHub Private RegistriesAPI version
2026-03-10.Changes:
PrivateRegistryAuthTypetype with constants fortoken,username_password,oidc_azure,oidc_aws, andoidc_jfrogCreateOrganizationPrivateRegistryandUpdateOrganizationPrivateRegistry:AuthType,TenantID,ClientID,AWSRegion,AccountID,RoleName,Domain,DomainOwner,JFrogOIDCProviderName,Audience,IdentityMappingNameReplacesBasefield to both Create and Update request structsSelectedRepositoryIDsfield toPrivateRegistryresponse structEncryptedValueandKeyIDinCreateOrganizationPrivateRegistryto
*stringwithomitempty(should be omitted for OIDC auth types)UpdateOrganizationPrivateRegistry()to return(*Response, error)since the API now returns 204 No Content
API docs: https://docs.github.com/rest/private-registries/organization-configurations?apiVersion=2026-03-10
Fixes: #4158.