Skip to content

Commit

Permalink
add support to scaffold webhooks for core types and external ones
Browse files Browse the repository at this point in the history
  • Loading branch information
@camilamacedo86
camilamacedo86 committed Oct 9, 2024
1 parent e7b0d93 commit 2c8a24a
Show file tree
Hide file tree
Showing 36 changed files with 1,388 additions and 373 deletions.
1 change: 0 additions & 1 deletion docs/book/src/SUMMARY.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,6 @@
- [Kind for Dev & CI](reference/kind.md)
- [What's a webhook?](reference/webhook-overview.md)
- [Admission webhook](reference/admission-webhook.md)
- [Webhooks for Core Types](reference/webhook-for-core-types.md)
- [Markers for Config/Code Generation](./reference/markers.md)

- [CRD Generation](./reference/markers/crd.md)
Expand Down
45 changes: 23 additions & 22 deletions docs/book/src/reference/project-config.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -130,29 +130,30 @@ version: "3"

Now let's check its layout fields definition:

| Field | Description |
|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `layout` | Defines the global plugins, e.g. a project `init` with `--plugins="go/v4,deploy-image/v1-alpha"` means that any sub-command used will always call its implementation for both plugins in a chain. |
| `domain` | Store the domain of the project. This information can be provided by the user when the project is generate with the `init` sub-command and the `domain` flag. |
| `plugins` | Defines the plugins used to do custom scaffolding, e.g. to use the optional `deploy-image/v1-alpha` plugin to do scaffolding for just a specific api via the command `kubebuider create api [options] --plugins=deploy-image/v1-alpha`. |
| `projectName` | The name of the project. This will be used to scaffold the manager data. By default it is the name of the project directory, however, it can be provided by the user in the `init` sub-command via the `--project-name` flag. |
| `repo` | The project repository which is the Golang module, e.g `github.com/example/myproject-operator`. |
| `resources` | An array of all resources which were scaffolded in the project. |
| `resources.api` | The API scaffolded in the project via the sub-command `create api`. |
| `resources.api.crdVersion` | The Kubernetes API version (`apiVersion`) used to do the scaffolding for the CRD resource. |
| `resources.api.namespaced` | The API RBAC permissions which can be namespaced or cluster scoped. |
| `resources.controller` | Indicates whether a controller was scaffolded for the API. |
| `resources.domain` | The domain of the resource which was provided by the `--domain` flag when the project was initialized or via the flag `--external-api-domain` when it was used to scaffold controllers for an [External Type][external-type]. |
| `resources.group` | The GKV group of the resource which is provided by the `--group` flag when the sub-command `create api` is used. |
| `resources.version` | The GKV version of the resource which is provided by the `--version` flag when the sub-command `create api` is used. |
| `resources.kind` | Store GKV Kind of the resource which is provided by the `--kind` flag when the sub-command `create api` is used. |
| Field | Description |
|-------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `layout` | Defines the global plugins, e.g. a project `init` with `--plugins="go/v4,deploy-image/v1-alpha"` means that any sub-command used will always call its implementation for both plugins in a chain. |
| `domain` | Store the domain of the project. This information can be provided by the user when the project is generate with the `init` sub-command and the `domain` flag. |
| `plugins` | Defines the plugins used to do custom scaffolding, e.g. to use the optional `deploy-image/v1-alpha` plugin to do scaffolding for just a specific api via the command `kubebuider create api [options] --plugins=deploy-image/v1-alpha`. |
| `projectName` | The name of the project. This will be used to scaffold the manager data. By default it is the name of the project directory, however, it can be provided by the user in the `init` sub-command via the `--project-name` flag. |
| `repo` | The project repository which is the Golang module, e.g `github.com/example/myproject-operator`. |
| `resources` | An array of all resources which were scaffolded in the project. |
| `resources.api` | The API scaffolded in the project via the sub-command `create api`. |
| `resources.api.crdVersion` | The Kubernetes API version (`apiVersion`) used to do the scaffolding for the CRD resource. |
| `resources.api.namespaced` | The API RBAC permissions which can be namespaced or cluster scoped. |
| `resources.controller` | Indicates whether a controller was scaffolded for the API. |
| `resources.domain` | The domain of the resource which was provided by the `--domain` flag when the project was initialized or via the flag `--external-api-domain` when it was used to scaffold controllers for an [External Type][external-type]. |
| `resources.group` | The GKV group of the resource which is provided by the `--group` flag when the sub-command `create api` is used. |
| `resources.version` | The GKV version of the resource which is provided by the `--version` flag when the sub-command `create api` is used. |
| `resources.kind` | Store GKV Kind of the resource which is provided by the `--kind` flag when the sub-command `create api` is used. |
| `resources.path` | The import path for the API resource. It will be `<repo>/api/<kind>` unless the API added to the project is an external or core-type. For the core-types scenarios, the paths used are mapped [here][core-types]. Or either the path informed by the flag `--external-api-path` |
| `resources.external` | It is `true` when the flag `--external-api-path` was used to generated the scaffold for an [External Type][external-type]. |
| `resources.webhooks` | Store the webhooks data when the sub-command `create webhook` is used. |
| `resources.webhooks.webhookVersion` | The Kubernetes API version (`apiVersion`) used to scaffold the webhook resource. |
| `resources.webhooks.conversion` | It is `true` when the webhook was scaffold with the `--conversion` flag which means that is a conversion webhook. |
| `resources.webhooks.defaulting` | It is `true` when the webhook was scaffold with the `--defaulting` flag which means that is a defaulting webhook. |
| `resources.webhooks.validation` | It is `true` when the webhook was scaffold with the `--programmatic-validation` flag which means that is a validation webhook. |
| `resources.core` | It is `true` when the group used is from Kubernetes API and the API resource is not defined on the project. |
| `resources.external` | It is `true` when the flag `--external-api-path` was used to generated the scaffold for an [External Type][external-type]. |
| `resources.webhooks` | Store the webhooks data when the sub-command `create webhook` is used. |
| `resources.webhooks.webhookVersion` | The Kubernetes API version (`apiVersion`) used to scaffold the webhook resource. |
| `resources.webhooks.conversion` | It is `true` when the webhook was scaffold with the `--conversion` flag which means that is a conversion webhook. |
| `resources.webhooks.defaulting` | It is `true` when the webhook was scaffold with the `--defaulting` flag which means that is a defaulting webhook. |
| `resources.webhooks.validation` | It is `true` when the webhook was scaffold with the `--programmatic-validation` flag which means that is a validation webhook. |

[project]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/testdata/project-v3/PROJECT
[versioning]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#Versioning
Expand Down
25 changes: 9 additions & 16 deletions docs/book/src/reference/using_an_external_resource.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -75,15 +75,11 @@ definitions since the type is defined in an external project.

### Creating a Webhook to Manage an External Type

<aside>
<H1> Support </H1>
Following an example:

Webhook support for external types is not currently automated by the tool.
However, you can still use the tool to scaffold the webhook setup and make
manual adjustments as needed. For guidance, you can follow a similar approach as
described in the section [Webhooks for Core Types][webhook-for-core-types].

</aside>
```shell
kubebuilder create webhook --group certmanager --version v1 --kind Issuer --defaulting --programmatic-validation --external-api-path=github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1 --external-api-domain=cert-manager.io
```

## Managing Core Types

Expand Down Expand Up @@ -169,18 +165,15 @@ Also, the RBAC for the above markers:
- update
```
```

This scaffolds a controller for the Core type `corev1.Pod` but skips creating new resource
definitions since the type is already defined in the Kubernetes API.

### Creating a Webhook to Manage a Core Type

<aside>
<H1> Support </H1>

Webhook support for Core Types is not currently automated by the tool. However, you can still use the tool to scaffold the webhook setup and make manual adjustments as needed. For guidance, you can follow [Webhooks for Core Types][webhook-for-core-types].
You will run the command with the Core Type data, just as you would for controllers.
See an example:

</aside>
```go
kubebuilder create webhook --group core --version v1 --kind Pod --programmatic-validation
```

[webhook-for-core-types]: ./webhook-for-core-types.md
Loading

0 comments on commit 2c8a24a

Please sign in to comment.