Repository navigation
[FEAT cloudctl] - Simplify sync command with persisted Greenhouse connection config #79
Description
User Story
As a cloudctl user, I want to run
cloudctl syncwithout flags after a one-time setup, so that syncing my kubeconfig is a single command rather than a long invocation.
Description
The current sync command requires at minimum --greenhouse-cluster-namespace on every invocation, and in practice users also need --greenhouse-cluster-context and sometimes --greenhouse-cluster-kubeconfig when the Greenhouse cluster is just one context among many in their default kubeconfig. This makes the command too verbose for daily use.
Current typical real-world invocation:
cloudctl sync \
--greenhouse-cluster-namespace my-org \
--greenhouse-cluster-context greenhouse \
--greenhouse-cluster-kubeconfig ~/.kube/config \
--auth-type exec-plugin \
--kubelogin-path /path/to/kubelogin
These values are stable per user and should only need to be provided once. The fix is to persist them via cloudctl config (the profile mechanism from the set/env issue) so that cloudctl sync with no flags works after a one-time setup. Additionally, --kubelogin-path should default to the version-pinned kubelogin binary managed by cloudctl (once the logon issue lands) rather than requiring kubelogin to be on $PATH.
Acceptance Criteria
-
--greenhouse-cluster-namespace,--greenhouse-cluster-context,--greenhouse-cluster-kubeconfigcan be persisted to cloudctl config and used as defaults bysync - Explicit flags always override persisted config
-
--kubelogin-pathdefaults to the cloudctl-managed version-pinned kubelogin binary when available, falling back tokubeloginon$PATH -
cloudctl syncwith no flags and a valid persisted config produces the same result as the full flag invocation - Missing required config (namespace not set anywhere) produces a clear error pointing to the one-time setup step
Reference Issues
Epic: #70
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsSprint Backlog
Activity
github-actions commentedon Aug 31, 2026
Thanks for opening this issue! 🎉
A maintainer will triage it within 5 business days. You can learn more about our issue workflow in the Issue Lifecycle documentation.
In the meantime, please make sure you have provided:
This helps us route your issue faster.