-
Notifications
You must be signed in to change notification settings - Fork 115
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
Make apiVersion
and kind
typing more precise
#341
Conversation
The first time around on this, I missed some of the properties that are exceptions -- e.g., @lblackstone please do double check this to make sure I'm not missing any other exceptions to this rule... I'm leaving the second commit as a standalone for now, rather than squashing it with the previous so you can take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming I understand what you mean by "top-level resource type", there are a few types here that appear to be nested fields (i.e. can't create these resources directly with the API).
- DeploymentRollback
- Scale
- APIGroup
- APIResourceList
- APIVersions
- DeleteOptions
- Status
- Eviction
71e51e1
to
7c2acbe
Compare
In Kubernetes resource implementations of `pulumi.CustomResource`, every top-level resource type has two fields: apiVersion?: pulumi.Input<string> kind?: pulumi.Input<string> These types could be more correct. For example, in the case of apps/v1/Deployment, we might instead write: apiVersion?: pulumi.Input<'apps/v1'> kind?: pulumi.Input<'Deployment'> This commit does exactly this. Fixes #315.
7c2acbe
to
405e8e0
Compare
We've agreed to keep |
In Kubernetes resource implementations of
pulumi.CustomResource
, everytop-level resource type has two fields:
These types could be more correct. For example, in the case of
apps/v1/Deployment, we might instead write:
This commit does exactly this.
Fixes #315.