[BUG] Operator Misconfigures CRD Conversion Webhooks

[adambkaplan]

Is there an existing issue for this?

• I have searched the existing issues

Kubernetes Version

1.32.z

Shipwright Version

v0.15.0 (preview)

Current Behavior

When the operator installs the Shipwright build controllers in a namespace other than shipwright-build, the conversion webhook for the build v1alpha1 APIs are misconfigured.

Expected Behavior

CRDs with conversion webhooks are configured to point to the correct namespace.

Steps To Reproduce

1. Install Shipwright operator (with Tekton)
2. Create ShipwrightBuild instance with a targetNamespace other than shipwright-build.
3. Attempt to create a Build/BuildRun object with the v1alpha1 API.

Anything else?

No response

[adambkaplan]

@ayushsatyam146 @sayan-biswas is this still a bug?

[IrvingMg]

I ran these steps to verify conversion webhooks (skipping operator installation):

1. Create a ShipwrightBuild with a shipwright-custom targetNamespace

kubectl apply -f - <<'EOF'                                                                                                                                                                                      
apiVersion: operator.shipwright.io/v1alpha1                                                                                                                                                                     
kind: ShipwrightBuild                                                                                                                                                                                           
metadata:                                                                                                                                                                                                       
  name: shipwright-operator                                                                                                                                                                                     
spec:
  targetNamespace: shipwright-custom
EOF

2. Verify Shipwright components are running in the custom namespace

kubectl get pods -n shipwright-custom
NAME                                          READY   STATUS    RESTARTS   AGE
shipwright-build-controller-cfdbc7996-6wlfj   1/1     Running   0          20s
shipwright-build-webhook-cbb48cdc-b8vmr       1/1     Running   0          20s

3. Create a v1alpha1 Build object to confirm the conversion webhook works

kubectl apply -f - <<'EOF'
apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
  name: test-build
  namespace: default
spec:
  source:
    url: https://github.com/shipwright-io/sample-go
  strategy:
    name: ko
    kind: ClusterBuildStrategy
  output:
    image: registry.example.com/test:latest
EOF

4. Verify the object was converted and stored as v1beta1

kubectl get build test-build -o jsonpath='{.apiVersion}'
shipwright.io/v1beta1

5. Verify CRD conversion webhooks point to the correct namespace

kubectl get crd builds.shipwright.io -o jsonpath='{.spec.conversion.webhook.clientConfig.service}' | jq .
kubectl get crd buildruns.shipwright.io -o jsonpath='{.spec.conversion.webhook.clientConfig.service}' | jq .

Both should show "namespace": "shipwright-custom":

{
  "name": "shp-build-webhook",
  "namespace": "shipwright-custom",
  "path": "/convert",
  "port": 443
}

So, it looks like this is no longer an issue.

/close

[openshift-ci]

@IrvingMg: Closing this issue.

Details

In response to this:

I ran these steps to verify conversion webhooks (skipping operator installation):

1. Create a ShipwrightBuild with a shipwright-custom targetNamespace

kubectl apply -f - <<'EOF'                                                                                                                                                                                      
apiVersion: operator.shipwright.io/v1alpha1                                                                                                                                                                     
kind: ShipwrightBuild                                                                                                                                                                                           
metadata:                                                                                                                                                                                                       
 name: shipwright-operator                                                                                                                                                                                     
spec:
 targetNamespace: shipwright-custom
EOF

2. Verify Shipwright components are running in the custom namespace

kubectl get pods -n shipwright-custom
NAME                                          READY   STATUS    RESTARTS   AGE
shipwright-build-controller-cfdbc7996-6wlfj   1/1     Running   0          20s
shipwright-build-webhook-cbb48cdc-b8vmr       1/1     Running   0          20s

3. Create a v1alpha1 Build object to confirm the conversion webhook works

kubectl apply -f - <<'EOF'
apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
 name: test-build
 namespace: default
spec:
 source:
   url: https://github.com/shipwright-io/sample-go
 strategy:
   name: ko
   kind: ClusterBuildStrategy
 output:
   image: registry.example.com/test:latest
EOF

4. Verify the object was converted and stored as v1beta1

kubectl get build test-build -o jsonpath='{.apiVersion}'
shipwright.io/v1beta1

5. Verify CRD conversion webhooks point to the correct namespace

kubectl get crd builds.shipwright.io -o jsonpath='{.spec.conversion.webhook.clientConfig.service}' | jq .
kubectl get crd buildruns.shipwright.io -o jsonpath='{.spec.conversion.webhook.clientConfig.service}' | jq .

Both should show "namespace": "shipwright-custom":

{
 "name": "shp-build-webhook",
 "namespace": "shipwright-custom",
 "path": "/convert",
 "port": 443
}

So, it looks like this is no longer an issue.

/close

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.