NotificationsYou must be signed in to change notification settings
Fork947
Star10.5k

feat(cli): add CLI support for listing presets#18910

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Open

ssncferreira wants to merge1 commit intomain

base:main

Choose a base branch

fromssncferreira/cli-presets-list

Open

feat(cli): add CLI support for listing presets#18910

ssncferreira wants to merge1 commit intomainfromssncferreira/cli-presets-list

+427 −11

Conversation

Copy link

Contributor

ssncferreira commentedJul 17, 2025•
edited
Loading

Description

This PR introduces a newlist presets command to display presets correspondent to a template and template version.

Changes

Thelist presets command queries the available presets associated with a template and version, and outputs them in a readable format.

> coder templates versions presets list --helpUSAGE:  coder templates versions presets list [flags] <template> <version>  List all the presets of the specified template versionOPTIONS:  -O, --org string, $CODER_ORGANIZATION          Select which organization (uuid or name) to use.  -c, --column [name|parameters|default|prebuilds] (default: name,parameters,default,prebuilds)          Columns to display in table output.  -o, --output table|json (default: table)          Output format.

Related PR:#18912 - please consider both PRs together as they’re part of the same workflow
Relates to issue:#16594

feat(cli): add CLI support for listing presets

356fb39

github-actionsbot assignedssncferreira

Jul 17, 2025

ssncferreira commented

Jul 17, 2025

View reviewed changes

cli/templateversionpresets.go

		Long:FormatExamples(
		Example{
		Description:"List presets of a specific template version",
		Command:"coder templates versions presets list my-template my-template-version",

Copy link

ContributorAuthor

ssncferreiraJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Currently, thecoder templates versions presets list command requires both a template and a template version as positional arguments. However, it might be more user-friendly to only require the template name, andby default use the active template version.

We could also introduce a--template-version flag for cases where the user wants to explicitly list the presets of a specific template version.

Example usage:

# Lists presets for the active version of the templatecoder templates versions presets list my-template# Lists presets for a specific template versioncoder templates versions presets list my-template --template-version my-template-version

Let me know what you think

Copy link

Contributor

dannykoppingJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

coder templates versions presets list is too verbose. Since we're requiring the template name / version as args/flags, there's no need to mention them in the command IMHO.coder presets should suffice.

Copy link

Contributor

SasSwartJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I likecoder presets. I recall seeing the termpreset used in unrelated work in the frontend a few months ago. Perhaps just check that we won't have any namespacing conflicts if we shorten the command but otherwise I think its a good idea.

I think template version flag should be optional with the active version as a default.

ssncferreira marked this pull request as ready for review

July 17, 2025 09:12

ssncferreira requested a review fromaslilac as acode owner

July 17, 2025 09:13

ssncferreira requested review fromSasSwart anddannykopping

July 17, 2025 09:14

dannykopping requested changes

Jul 17, 2025

View reviewed changes

Copy link

Contributor

dannykopping left a comment•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Before I review further, I'd like to just address some confusion I have:

I'm not really understanding the point of this command.

Users need to be able to specify a preset when creating a workspace. Presumably this command is to allow a user to find out which presets exist so they can pass a value tocoder create.

However:coder create provides an interactive and non-interactive mode. If you supply a--template argument it'll use that value, otherwise interactively list all templates and prompt the user to select one.

I think presets should have the same experience. In other words, we likely don't need this command at all but rather we can move the logic you've already implemented tocoder create.

That will be the most consistent UX, I believe.

Let me put it another way: were we aware of the interactive nature ofcoder create? If so, did we decide to design it this way for a particular reason? I can see how this design might fall out of not knowing about the interactive mode.

cli/templateversionpresets.go

		Long:FormatExamples(
		Example{
		Description:"List presets of a specific template version",
		Command:"coder templates versions presets list my-template my-template-version",

Copy link

Contributor

dannykoppingJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Copy link

ContributorAuthor

ssncferreira commentedJul 17, 2025

Before I review further, I'd like to just address some confusion I have:
I'm not really understanding the point of this command.
Users need to be able to specify a preset when creating a workspace. Presumably this command is to allow a user to find out which presets exist so they can pass a value tocoder create.

Exactly! One of the goals of this command is to help users discover which presets are available for a given template version, especially in non-interactive, automated environments. The ability to apply a preset during workspace creation is implemented in#18912.

However:coder create provides an interactive and non-interactive mode. If you supply a--template argument it'll use that value, otherwise interactively list all templates and prompt the user to select one.
I think presets should have the same experience. In other words, we likely don't need this command at all but rather we can move the logic you've already implemented tocoder create.
That will be the most consistent UX, I believe.

I agree that presets should follow the same behavior in both interactive and non-interactive modes. While the current implementation doesn't include interactive support for presets, I think it absolutely should. I shared some thoughts on this here:https://github.com/coder/coder/pull/18912/files#r2212832022 including ideas on default selection, backward compatibility with scripting workflows, and introducing a "none" option.

That said, I believe this command is still valuable in non-interactive scenarios, where users might need to fetch the name of a preset to use during workspace creation.

Let me put it another way: were we aware of the interactive nature ofcoder create? If so, did we decide to design it this way for a particular reason? I can see how this design might fall out of not knowing about the interactive mode.

Yes, we’re aware of that! And while the interactive flow is great for users runningcoder create manually, we also need to support non-interactive usage, which is common in customer scripts and automation.

In those cases, users typically rely on:

coder templates list to discover templates,
coder templates versions list to discover template versions,
and now,coder templates versions presets list to discover presets (but I am open to a less verbose command 😅 )

This new command fits naturally into that pattern. It allows users to look up presets that they can then pass via--preset tocoder create, without requiring any prompts.

Right now, the CLI does not provide any information about presets, this command gives users a way to discover and inspect available presets for a given template and version.

ssncferreira mentioned this pull request

Jul 17, 2025

feat(cli): add CLI support for creating a workspace with preset#18912

Open

SasSwart reviewed

Jul 17, 2025

View reviewed changes

Copy link

Contributor

SasSwart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks great@ssncferreira. Some minor comments. I'll check back once we've finalized the thread Danny opened.

codersdk/presets.go

		@@ -15,6 +15,7 @@ type Preset struct {
		Namestring
		Parameters []PresetParameter
		Defaultbool
		Prebuilds*int

Copy link

Contributor

SasSwartJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Consider clarifying the naming to communicate whether this is the desired number of prebuilds or the eligible number of prebuilds. I can see from elsewhere that its the desired number, but we've spoken in the past about showing how many prebuilds are eligible in the frontend before. Would be good to leave room for both.

coderd/presets.go

		@@ -38,12 +39,21 @@ func (api API) templateVersionPresets(rw http.ResponseWriter, r http.Request)
		return
		}

		getPrebuildInstances:=func(desiredInstances sql.NullInt32)*int {

Copy link

Contributor

SasSwartJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

this name implies fetching from somewhere, but it only does a type conversion. perhaps consider a more descriptive name?

cli/templateversionpresets.go

		}

		iflen(presets)==0 {
		returnxerrors.Errorf("no presets found for template %q and template-version %q",template.Name,version.Name)

Copy link

Contributor

SasSwartJul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Should this be an error? Or just an empty list?

dannykopping self-requested a review

July 17, 2025 16:56

Copy link

Contributor

dannykopping commentedJul 17, 2025

Before I review further, I'd like to just address some confusion I have:
I'm not really understanding the point of this command.
Users need to be able to specify a preset when creating a workspace. Presumably this command is to allow a user to find out which presets exist so they can pass a value tocoder create.
Exactly! One of the goals of this command is to help users discover which presets are available for a given template version, especially in non-interactive, automated environments. The ability to apply a preset during workspace creation is implemented in#18912.
However:coder create provides an interactive and non-interactive mode. If you supply a--template argument it'll use that value, otherwise interactively list all templates and prompt the user to select one.
I think presets should have the same experience. In other words, we likely don't need this command at all but rather we can move the logic you've already implemented tocoder create.
That will be the most consistent UX, I believe.
I agree that presets should follow the same behavior in both interactive and non-interactive modes. While the current implementation doesn't include interactive support for presets, I think it absolutely should. I shared some thoughts on this here:#18912 (files) including ideas on default selection, backward compatibility with scripting workflows, and introducing a "none" option.
That said, I believe this command is still valuable in non-interactive scenarios, where users might need to fetch the name of a preset to use during workspace creation.
Let me put it another way: were we aware of the interactive nature ofcoder create? If so, did we decide to design it this way for a particular reason? I can see how this design might fall out of not knowing about the interactive mode.
Yes, we’re aware of that! And while the interactive flow is great for users runningcoder create manually, we also need to support non-interactive usage, which is common in customer scripts and automation.
In those cases, users typically rely on:
coder templates list to discover templates,
coder templates versions list to discover template versions,
and now,coder templates versions presets list to discover presets (but I am open to a less verbose command 😅 )
This new command fits naturally into that pattern. It allows users to look up presets that they can then pass via--preset tocoder create, without requiring any prompts.
Right now, the CLI does not provide any information about presets, this command gives users a way to discover and inspect available presets for a given template and version.

My apologies@ssncferreira! I didn't see the other PR, maybe mention it in the description of this one?
I thought this PR represented the full scope of what was to be done; makes a lot of sense in the wider context.
Thanks!

Copy link

ContributorAuthor

ssncferreira commentedJul 17, 2025•
edited
Loading

My apologies@ssncferreira! I didn't see the other PR, maybe mention it in the description of this one? I thought this PR represented the full scope of what was to be done; makes a lot of sense in the wider context. Thanks!

No worries@dannykopping 😊 it was a totally fair point, and I really appreciate you taking the time to make sure the UX of the CLI is thoughtfully considered. I've updated the description of both PRs to reference each other for clarity. Let me know if anything else is unclear!

Labels

None yet

3 participants

Movatterモバイル変換

feat(cli): add CLI support for listing presets#18910

Are you sure you want to change the base?

feat(cli): add CLI support for listing presets#18910

Conversation

ssncferreira commentedJul 17, 2025• editedLoading Uh oh!There was an error while loading.Please reload this page.

Uh oh!

Description

Changes

Uh oh!

ssncferreiraJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

dannykoppingJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

SasSwartJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

dannykopping left a comment• editedLoading Uh oh!There was an error while loading.Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dannykoppingJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

ssncferreira commentedJul 17, 2025

Uh oh!

SasSwart left a comment

Choose a reason for hiding this comment

Uh oh!

SasSwartJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

SasSwartJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

SasSwartJul 17, 2025

Choose a reason for hiding this comment

Uh oh!

dannykopping commentedJul 17, 2025

Uh oh!

ssncferreira commentedJul 17, 2025• editedLoading Uh oh!There was an error while loading.Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ssncferreira commentedJul 17, 2025•
edited
Loading

dannykopping left a comment•
edited
Loading

ssncferreira commentedJul 17, 2025•
edited
Loading