✨ Add custom path option for webhooks

[damsien]

Closes #4295 ! This PR brings a way to configure custom webhook path for the defaulting and validating webhooks in the kubebuilder cli.

Two new flags are added for the kubebuilder create webhook command: --defaulting-custom-path & --validating-custom-path. Both can be used independently.

Usage:

kubebuilder create webhook \
    --group mygroup.io --kind MyResource --version v1alpha1 \
    --defaulting --programmatic-validation \
    --defaulting-custom-path=/my-custom-defaulting-webhook-path \
    --validating-custom-path=/my-custom-validating-webhook-path

When used, it will:

1. Change the // +kubebuilder:webhook:path go marker.
2. Add WithValidatorCustomPath(...). or/and WithDefaulterCustomPath(...). to the webhook setuper function.

Result from the example above:

func SetupMyResourceWebhookWithManager(mgr ctrl.Manager) error {
	return ctrl.NewWebhookManagedBy(mgr).For(&mygroupiov1alpha1.MyResource{}).
		WithValidator(&MyResourceCustomValidator{}).
		WithDefaulter(&MyResourceCustomDefaulter{}).
		WithValidatorCustomPath("/my-custom-validating-webhook-path").
		WithDefaulterCustomPath("/my-custom-defaulting-webhook-path").
		Complete()
}

// +kubebuilder:webhook:path=/my-custom-defaulting-webhook-path,mutating=true,failurePolicy=fail,sideEffects=None,groups=mygroup.io,resources=myresources,verbs=create;update,versions=v1alpha1,name=mmyresource-v1alpha1.kb.io,admissionReviewVersions=v1

...

// +kubebuilder:webhook:path=/my-custom-validating-webhook-path,mutating=false,failurePolicy=fail,sideEffects=None,groups=mygroup.io,resources=myresources,verbs=create;update,versions=v1alpha1,name=vmyresource-v1alpha1.kb.io,admissionReviewVersions=v1

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: damsien
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @damsien. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[camilamacedo86]

That’s great work, thank you! 🎉
The implementation looks solid at a glance.

However, since this introduces API changes, I’ll need a bit more time to review it carefully and fully assess the impact.

A couple of things we should also make sure of before merging:

• This should be compatible with the alpha generate command — we’ll likely need to include logic to ensure the project is re-scaffolded correctly with the new option.

• It should also work seamlessly with the Helm charts plugin (helm.kubebuilder.io/v1-alpha) — could you confirm compatibility or add test coverage for that?

Thanks again for the contribution! I’ll follow up with a more detailed review soon.

[damsien]

Thank you for your quick comment!

we’ll likely need to include logic to ensure the project is re-scaffolded correctly with the new option.

What do you mean by "the project is re-scaffolded"?

could you confirm compatibility or add test coverage for that?

I didn't test it with the helm chart plugin. Also, since I never worked with the helm plugin, I don't really know where to start to confirm the compatibility 😅. Could you please provide me the test file where I should write the new test?

I don't really understand where there should be an incompatibility with the helm plugin since my feature is only related to the webhook file that is created using the CLI (actually it only affects the content of the webhook file, and it does not scaffold any other file). The feature is not related at all with the delivery of the user's operator.