-
Notifications
You must be signed in to change notification settings - Fork 62
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
[BUG]: types for octokit.rest.repos.createInOrg does not accept "internal" as visibility, despite it being valid #383
Comments
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with |
Perhaps the types present in https://github.com/octokit/plugin-enterprise-cloud.js or https://github.com/octokit/plugin-enterprise-server.js could help here? |
Unfortunately those plugins don't adapt type for common endpoints between GitHub.com, GHES and GHEC. @devjoes Is this for an enterprise version of github, or the standard GitHub.com? |
@kfcampbell @wolfy1339 the ergonomics of GHES / GHEC endpoints are much better implemented in https://github.com/octokit/octokit.js, see this update octokit/octokit.js#2127 (comment). It's hard to make types work well for targets other than dotcom with the way types are implemented for current Octokit.js |
What happened?
I upgraded Octokit to version v20 of the API (by upgrading @actions/github to 6.0.0). This removed the
internal
option forvisibility
when callingoctokit.rest.repos.createInOrg
.When trying to call this method with either of the remaining options
public
orprivate
and creating a repo within an organisation I get the errorYou need admin access to the organization before adding a repository to it.
.If I bypass type checking and forcibly set this option back to
internal
then it works. This leads me to believe that this is an issue with the generated types.d.ts (or rather the underlying OpenApi spec.)This is the workaround - notice the cast to
any
Versions
@actions/github: 6.0.0
@octokit/openapi-types: 19.0.2
typescript: 5.1.6
node: 20.7.0
npm: 10.1.0
Relevant log output
Code of Conduct
The text was updated successfully, but these errors were encountered: