🐛 Fix builder engage options to merge instead of replace

[stanfordpeng]

Summary

This PR fixes the EngageOptions behavior in ApplyToFor() and ApplyToOwns() to merge options field-by-field instead of replacing the entire struct. This makes the behavior consistent with ApplyToWatches(), which already correctly merges options. See #93

Problem

When using the multicluster builder with multiple EngageOptions, the last option would overwrite all previous options instead of merging them:

mcbuilder.ControllerManagedBy(mcMgr).
    For(&MyResource{},
        mcbuilder.WithEngageWithLocalCluster(true),
        mcbuilder.WithEngageWithProviderClusters(false),
    ).
    Complete(reconciler)

Due to the implementation in ApplyToFor() and ApplyToOwns(), only engageWithProviderClusters=false would be applied, while engageWithLocalCluster would remain nil and fall back to the default.

This made it impossible to configure hub-and-spoke patterns where you want to watch resources in the local cluster but access remote clusters via GetCluster().

Solution

Changed ApplyToFor() and ApplyToOwns() to merge options field-by-field, matching the existing pattern in ApplyToWatches():

func (w EngageOptions) ApplyToFor(opts *ForInput) {
    if w.engageWithLocalCluster != nil {
        local := *w.engageWithLocalCluster
        opts.engageWithLocalCluster = &local
    }
    if w.engageWithProviderClusters != nil {
        provider := *w.engageWithProviderClusters
        opts.engageWithProviderClusters = &provider
    }
}

This properly merges each field independently while creating new pointer instances to avoid aliasing issues.

Testing

Verified that the hub-and-spoke pattern now works correctly by testing with the following configuration:

mcbuilder.ControllerManagedBy(mcMgr).
    For(&XCR{},
        mcbuilder.WithEngageWithLocalCluster(true),
        mcbuilder.WithEngageWithProviderClusters(false),
    ).
    Complete(reconciler)

The controller now correctly watches only the local cluster while maintaining access to remote clusters via the manager.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: stanfordpeng / name: Stan (9e8b8a8)

[k8s-ci-robot]

Welcome @stanfordpeng!

It looks like this is your first PR to kubernetes-sigs/multicluster-runtime 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/multicluster-runtime has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[embik]

This looks good, please just remove the "Fixes" part from the commit message (as you can see, the bot doesn't like that).

[embik]

/approve

Thank you for the contribution!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: embik, stanfordpeng

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [embik]

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]

LGTM label has been added.

Git tree hash: f696cb1ee6db96d64bed2a00724e10e3406c12fd