[CLI-109] Add 'ccloud ps1' helper for configuring PS1 prompt#197
Conversation
Codecov Report
@@ Coverage Diff @@
## master #197 +/- ##
=========================================
Coverage ? 41.72%
=========================================
Files ? 44
Lines ? 3319
Branches ? 0
=========================================
Hits ? 1385
Misses ? 1757
Partials ? 177
Continue to review full report at Codecov.
|
…ause relative directories don't work in PS1 when you cd around
|
| kafka Manage Apache Kafka. | ||
| login Login to Confluent Cloud. | ||
| logout Logout of Confluent Cloud. | ||
| ps1 Print a prompt-string suitable for the PS1 prompt. |
There was a problem hiding this comment.
If I don't know what a PS1 prompt is by name (but know what it looks like when I use one) it would be helpful if these comments explained a bit more what it is so I know that I'd want to use it.
There was a problem hiding this comment.
Suggestions on a suitable short description?
Also, I was actually wondering if ps1 was even a good name for this command. We could just call it prompt... but I wasn't if we'd ever want that for something else (like how you enter mysql shell or ksql or https://github.com/c-bata/kube-prompt... but I guess technically you're now in a shell not a prompt).
Comps:
| func inferColorBasedOnEnvName(name string) func(a ...interface{}) string { | ||
| name = strings.ToLower(name) | ||
| if strings.Contains(name, "prod") || strings.Contains(name, "prd") { | ||
| return red |
There was a problem hiding this comment.
do colors have to be specified in code or can they be specified with tokens on the command line / prompt?
maybe a general purpose solution here would be to have a map of names->colors in a (the) config file, though reading a file to display the shell prompt sounds like such an inefficient thing 😅
There was a problem hiding this comment.
ha, I definitely wondered about this too. There's just so many ways you might want to customize colors.
Take the premise that you'd have a map of names -> colors. But names of what? e.g., context name, account name, kafka cluster name? (We're currently just searching through all three for a match for the magic common env names of prod/prd, stag/stg, or dev.) So this is like a multidimensional config/would need a more complex ruleset to make it truly declarative.
And a different dimension -- We could read the config from a config file, pass it as an arg, pass it as an ENV VAR, etc
My current thoughts (without diving all the way in here) is that customers could "recolor" this however they want through some clever workarounds. Kind of like how this random repo usage works. For example, to colorize the output based on the context name alone:
[[ "$(confluent ps1 -g -f '%c') =~ "prod" ]] && color=red || color=blue
PS1='%{$fg[$color]%}$(confluent ps1 -g)%{$reset_color%}'
(this won't actually work as its a bad mix of zsh and bash-isms but it gets the idea across; you'd just use ansi color codes in bash instead.. Speaking of, i wonder if these color codes introduced in this PR work in zsh)
EDIT: this wouldn't work as-is, you'd have to wrap it in a function to dynamically update the colors as your context changes. Maybe something like
func confluent_ps1() {
[[ "$(confluent ps1 -g -f '%c') =~ "prod" ]] && color=red || color=blue
return '%{$fg[$color]%}$(confluent ps1 -g)%{$reset_color%}'
}
PS1='$(confluent_ps1)'
There was a problem hiding this comment.
In any case, I think we can definitely do this as a follow-up / when a customer requests it. :)
There was a problem hiding this comment.
Ok, fine, I switched from dynamic colors based on env to user-defined colors but they can't be dynamic yet.
Also added a symbol to identify this prompt output as coming from Confluent. We're limited to unicode, so I found the closest one to the Confluent logo (which is ☪️). This was more for fun than anything, no idea if product will approve. :)
Default Output Examples
This is the current default output format in various terminals.
Subawesome bash terminal (inside GoLand):

Configuration
This is the default config string:
({{color "blue" "%X"}}|{{color "red" "%E"}}:{{color "cyan" "%K"}})
Here's the docs for configuring colors:
There are special functions used for controlling colors.
- {{color "" "some text"}}
- {{fgcolor "" "some text"}}
- {{bgcolor "color>" "some text"}}
- {{colorattr "" "some text"}}
Available colors: black, red, green, yellow, blue, magenta, cyan, white
Available attributes: bold, underline, invert (swaps the fg/bg colors)Examples:
- {{color "red" "some text" | colorattr "bold" | bgcolor "blue"}}
- {{color "red"}} some text here {{resetcolor}}
Notes:
- 'color' is just an alias of 'fgcolor'
- calling 'resetcolor' will reset all color attributes, not just the most recently set
You can disable color output by passing the flag '--no-color'.
There was a problem hiding this comment.
David Hyde (DABH)
left a comment
There was a problem hiding this comment.
Looks pretty good, left a few comments/questions
…caping curly braces in help message; fix help message to customize fmt env var per CLI name
David Hyde (DABH)
left a comment
There was a problem hiding this comment.
LGTM now, very cool feature!
|
Changed format in help/usage message. This is what I expect most people will copy/paste.
Bash: Zsh: |
(cherry picked from commit 25136d6ec60736d59f717a41428561f52ffa8c66)
…nterval, add Delay Addresses Channing review #11/#13/#14 on PR #197 (companion generator PR) by tightening the wait API and the Flink statement reference adoption. * pkg/wait: rename Options.Tick / PhaseOptions.Tick to PollInterval to match terraform-provider-confluent's StateChangeConf vocabulary. Add Delay (initial sleep before the first Fetch) mirroring StateChangeConf.Delay — gives the API a moment to materialize the resource after a POST, reducing eventually-consistent 404s on the first poll. New tests TestPoll_DelayPostponesFirstFetch and TestPoll_DelayRespectsCtxCancellation cover the contract. * Flink statement create (cloud + on-prem): drop the clierrors alias on pkg/errors and use direct == compare against wait.ErrFailed / wait.ErrTimeout. The wait sentinels are package-level vars returned directly from Poll (never wrapped), so == is correct and avoids importing stdlib errors alongside the CLI errors package — which matches the rest of the codebase's import convention. * Timeout error now includes the latest observed phase: "wait timed out: statement \"x\" is still in phase \"PENDING\"" rather than the bare "wait timed out". Updated create-wait-timeout.golden accordingly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>





Inspired by https://github.com/djl/vcprompt that a customer mentioned in their zendesk ticket.
https://confluentinc.atlassian.net/browse/CLI-109
Default usage:
Bash prompt:

Zsh prompt:

Subawesome bash prompt (Goland terminal):

We can change our environment and see
Confluentchange toStagingin the prompt:(Note: this reveals a potential bug- the kafka cluster isn't updated when we switch envs)
We can change our kafka cluster and
superfasterchanges toprestagin the prompt:You can also customize the prompt with format args:
Or use an env var for more sophisticated prompts with colors -- env var avoids quote/escape hell
Open Questions
should we call this commandrenamed toccloud ps1orccloud prompt-stringor something else?ccloud promptdo we like having colors like this? (red=prod, yellow=stag, green=dev)are we comfortable with "inferring" the environment like this?is this order of "inferring" the environment from context, then environment, then kafka cluster name, correct?PR has been updated to only have static user-defined colors for now
Long Help