fix(api): prevent unnecessary default values in options field - #4158

@Pranaysaha2: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign anithapriyanatarajan after the PR has been reviewed.
You can assign the PR to them by writing /assign @anithapriyanatarajan in a comment when ready.

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

The committers listed above are authorized under a signed CLA.

• ✅ login: Pranaysaha2 / name: Pranaysaha2 (c1b3fde)

@divyansh42 @enarha can you please review my pull request?

@Pranaysaha2 before we review further, we need clearer human verification on this PR.

This looks like a large API/behavior change (RawExtension migration, tests disabled, size/XXL), and we are seeing a lot of agent-authored PRs where the submitter cannot explain or own the change. Please reply in your own words (not a paste of the issue/PR template) with:

1. Why strongly typed objects in AdditionalOptions cause the unwanted defaults (e.g. creationTimestamp: null, maxReplicas: 0) — what layer writes those fields?
2. Why runtime.RawExtension is the right fix vs alternatives (e.g. *int32 pointers / omitempty / custom marshalling), and what compatibility impact this has on existing TektonConfig CRs and clients.
3. What you personally validated — which tests you ran, why transformer_additional_options_test.go is disabled, and what breaks if we merge without converting it.
4. Confirmation you understand this change and can support follow-ups if it regresses options handling in production.

Until that is answered, please do not ping reviewers for approval. /hold may be applied pending a concrete response.

/hold

@jkhelil, I have added my response.

Why strongly typed objects in AdditionalOptions cause the unwanted defaults (e.g. creationTimestamp: null, maxReplicas: 0) — what layer writes those fields?

1. When AdditionalOptions used strongly-typed Kubernetes objects (e.g., map[string]appsv1.Deployment), the default values were injected during JSON unmarshaling by the Kubernetes API machinery.

Specifically, when a user provides partial YAML like:

options:
  horizontalPodAutoscalers:
    tekton-pipelines-webhook:
      spec:
        minReplicas: 2

When user submits the YAML to API server, YAML converts to JSON. Kubernetes API server receives this JSON and need to validate this against CRD scheme. And Unmarshal it into the Go struct defined in additional_options.go
When json.Unmarshal deserializes into autoscalingv2.HorizontalPodAutoscaler, autoscalingv2.HorizontalPodAutoscaler struct (from k8s.io/api/autoscaling/v2):

type HorizontalPodAutoscaler struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   HorizontalPodAutoscalerSpec   `json:"spec,omitempty"`
    Status HorizontalPodAutoscalerStatus `json:"status,omitempty"`
}

During unmarshal, Go allocates memory for the entire struct, initializing ALL fields.
omitempty affects marshaling (struct → JSON): "don't output this field if it's zero", and it does NOT affect unmarshaling (JSON → struct): "fields not in JSON get zero values"

Why runtime.RawExtension is the right fix vs alternatives (e.g. *int32 pointers / omitempty / custom marshalling), and what compatibility impact this has on existing TektonConfig CRs and clients.

2. With the new code, with runtime.RawExtension, only the user's data is stored in the etcd server, and no zero values.

type AdditionalOptions struct {
    HorizontalPodAutoscalers map[string]runtime.RawExtension `json:"horizontalPodAutoscalers,omitempty"`
}

Earlier, the API server unmarshal into HorizontalPodAutoscaler struct, after that API server marshal for storage.
Now, API server unmarshals into RawExtension, and after that, the API server storage.
Later, in the reconciler RawExtension.Raw → Unmarshal to HPA struct (for processing only, never stored).

In the transformer code transformer_additional_options.go, hpaOptions has zero values, but we NEVER write this back to the CR, it only use it to update the manifest resources.

var hpaOptions autoscalingv2.HorizontalPodAutoscaler
if err := json.Unmarshal(rawExt.Raw, &hpaOptions); err != nil {
    return err
}

What you personally validated — which tests you ran, why transformer_additional_options_test.go is disabled, and what breaks if we merge without converting it.

3. I used make test and make lint for core unit tests and lint validations.
   For transformer_additional_options_test.go, the file is currently failing to compile (not actively disabled with build tags). It uses the old pattern: constructing AdditionalOptions with strongly typed maps like map[string]appsv1.Deployment{...}. Now that the struct expects map[string]runtime.RawExtension, all these test cases fail with type mismatch errors.

Confirmation you understand this change and can support follow-ups if it regresses options handling in production.

4. Yes, I understand this change and can support follow-ups.