Automate Uncommenting Webhook Blocks in `kustomize.yaml` When Scaffolding Webhooks

[camilamacedo86]

What do you want to happen?

Currently, when scaffolding webhooks (default or conversion or validation), users need to manually uncomment the relevant blocks in the config/default/kustomization.yaml file. This process can be automated to improve the user experience.

Problem

• When scaffolding default webhooks, users must manually uncomment the corresponding sections in the kustomization.yaml file.
• For conversion webhooks, the injected code requires further manual adjustments to uncomment specific blocks.
• In the e2e tests, the uncommenting is handled via shell scripts (example here), which could be avoided if the tool itself handles this step during scaffolding.

Solution

1. Automate Uncommenting:

   • Use the plugin utility methods (plugin/util/util.go) to automate the process of uncommenting code in kustomization.yaml during webhook scaffolding.
   • Update the scaffold logic in:
     • pkg/plugins/golang/v4/scaffolds/webhook.go
   • Add the required logic to handle default webhooks and conversion webhooks, similar to the example in api.go.

2. Raise Warnings:

   • If the tool cannot automatically uncomment the code (e.g., file issues or other constraints), it should raise a warning instead of throwing an error. This ensures the user knows what to fix manually without blocking the workflow.

3. Remove Shell Script Dependencies in CI:

   • Remove references in GitHub Actions that use shell scripts to uncomment blocks during e2e tests (example here).
   • Update CI workflows to validate the new behavior where the tool handles uncommenting automatically.

Benefits

• Users will no longer need to manually uncomment code in kustomization.yaml when scaffolding webhooks.
• Cleaner and more automated CI processes.
• Improved developer experience for kubebuilder users.
• Improve maintainability for our ci

Extra Labels

No response

[Dhairya-Dudhatra]

Hey @camilamacedo86 , can you please assign this to me ?

[mateusoliveira43]

@Dhairya-Dudhatra you can comment /assign and bot will do this for you :)

[Dhairya-Dudhatra]

/assign

[camilamacedo86]

What we must do:

If we run create webhook:

The, we will uncomment (if not yet) in the config/default/kustomize.ymal

#- ../certmanager

#- path: cert_metrics_manager_patch.yaml
#  target:
#    kind: Deployment

- path: manager_webhook_patch.yaml

#replacements:
# - source: # Uncomment the following block if you enable [METRICS-WITH-CERTS]
#     kind: Service
#     version: v1
#     name: controller-manager-metrics-service
#     fieldPath: metadata.name
#   targets:
#     - select:
#         kind: Certificate
#         group: cert-manager.io
#         version: v1
#         name: metrics-certs
#       fieldPaths:
#         - spec.dnsNames.0
#         - spec.dnsNames.1
#       options:
#         delimiter: '.'
#         index: 0
#         create: true
#
# - source:
#     kind: Service
#     version: v1
#     name: controller-manager-metrics-service
#     fieldPath: metadata.namespace
#   targets:
#     - select:
#         kind: Certificate
#         group: cert-manager.io
#         version: v1
#         name: metrics-certs
#       fieldPaths:
#         - spec.dnsNames.0
#         - spec.dnsNames.1
#       options:
#         delimiter: '.'
#         index: 1
#         create: true
#
# - source: # Uncomment the following block if you have any webhook
#     kind: Service
#     version: v1
#     name: webhook-service
#     fieldPath: .metadata.name # Name of the service
#   targets:
#     - select:
#         kind: Certificate
#         group: cert-manager.io
#         version: v1
#         name: serving-cert
#       fieldPaths:
#         - .spec.dnsNames.0
#         - .spec.dnsNames.1
#       options:
#         delimiter: '.'
#         index: 0
#         create: true
# - source:
#     kind: Service
#     version: v1
#     name: webhook-service
#     fieldPath: .metadata.namespace # Namespace of the service
#   targets:
#     - select:
#         kind: Certificate
#         group: cert-manager.io
#         version: v1
#         name: serving-cert
#       fieldPaths:
#         - .spec.dnsNames.0
#         - .spec.dnsNames.1
#       options:
#         delimiter: '.'
#         index: 1
#         create: true

Then:

• if the webhook is from the type --programmatic-validation, we will also uncomment its respective block.
• if the webhook is from the type --defaulting to the same
• if the webhook is firm, the type --conversion is the same (for this one, we need to use the resource data to create the string and then uncomment. ( See how we do that in our tests https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/e2e/v4/generate_test.go#L443-L448 and https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/e2e/v4/generate_test.go#L344-L376 )

Since when it happens the project will need to have the dependency with webhooks and we are uncomment the metrics as well, we need to uncomment the following in the config/prometheus/kustomization.yaml

# [PROMETHEUS WITH CERTMANAGER] The following patch configures the ServiceMonitor in ../prometheus
# to securely reference certificates created and managed by cert-manager.
# Additionally, ensure that you uncomment the [METRICS WITH CERTMANAGER] patch under config/default/kustomization.yaml
# to mount the "metrics-server-cert" secret in the Manager Deployment.
#patches:
#  - path: monitor_tls_patch.yaml
#    target:
#      kind: ServiceMonitor

So that we ensure that all places that will benefit from using cert-manager will be uncommented, and we are making the process easier for our users.

[akagami-harsh]

Hi @Dhairya-Dudhatra, are you still working on this issue? If not, I'd be happy to take it up. Please let me know. Thanks!

[Dhairya-Dudhatra]

@akagami-harsh Please go ahead.

[akagami-harsh]

/assign