Skip to content

[FEAT cloudctl] - Improved AuthInfo merging and deduplication logic #54

@onuryilmaz

Description

@onuryilmaz

[FEAT cloudctl] - Improved AuthInfo merging and deduplication logic

Labels

  • feature
  • enhancement
  • kubeconfig

Priority

(Medium) I'm annoyed but I'll live

User Story

As a user with many clusters sharing the same OIDC provider, I want cloudctl to minimize the number of duplicate users in my kubeconfig, so that it remains readable and manageable.

Description

The current authInfoEqual and generateAuthInfoKey logic in cmd/sync.go handles basic deduplication by comparing core credential fields while ignoring volatile tokens. However, as the number of clusters grows, the deduplication should be more robust. It should specifically focus on:

  1. Preferring existing user names in the local kubeconfig if the credentials match exactly.
  2. Handling a wider range of kubelogin arguments and ensuring they are consistently ordered during comparison.
  3. Improving the readability of the comparison logic, potentially moving it to a dedicated package or utility.

Acceptance Criteria

  • Refactor authInfoEqual and generateAuthInfoKey in cmd/sync.go for better readability and extensibility.
  • Implement logic in mergeKubeconfig to prefer existing user names from the local config when a matching AuthInfo is found.
  • Ensure all relevant ExecConfig fields (Env, InteractiveMode, etc.) are considered in the comparison if they affect authentication.
  • Add comprehensive unit tests in cmd/sync_test.go covering edge cases like identical credentials with different user names.
  • Use maps.Equal and other modern Go 1.25 idioms for cleaner comparisons.

Reference Issues

None

Metadata

Metadata

Assignees

No one assigned

    Labels

    backlogReady for sprint planning; triggers project additionenhancementImprovements to existing features, logic, or performance.featureNew functional capabilities or significant additions to the CLI.kubeconfigSpecifically related to kubeconfig parsing, merging, or managementneeds-refinementNeeds scoping before implementation

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    Sprint Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions