Kinda interesting that a combination of parameters would replace a name.

Good idea!

Yes, currently these workspaces are opened from "Open in Coder" or via an inhouse Chrome extension.

As a chrome extension

As from Open in Coder

@michaelbrewer thanks for bringing this idea to us 🙏. I see how this can be useful.

I see this can be challenging since a workspace can have many parameters, and their labels and values can be quite long. Would you have any other product reference that would display similar data to the users or would you have ideas on how we can do that? In the meantime, I'm going to think about this and see if I can come up with something 🤔.

For now :
I can pass in the "repo_name" to refill the workspace name for now.
Also for an open workspace I will see if I can add meta-data fields to identify what's open quickly.

Feature request wise:

Generating a name from the parameters could be too long, maybe just allow for a prefix to see the name might help. Ie: (repo_name)-(generated-name)

Allowing for filtering / search on workspace parameters would help admins and allowing users to select a parameter to the list view would be great like the git_url parameter.

I can see that this could extend to seeing the list of workspaces in vscode and JetBrains extensions.

Related to #11837

@michaelbrewer do you think this would be helpful to you #12694?

Could be i will try it out. I assume you can use this to filter workspaces by a parameter name? like repo url.

@BrunoQuaresma - would this filter pick up workspace metadata as well? For example we could flag that a workspace has uncommitted work, so we don't want to delete these unnecessarily.

#9477

cc.: @Emyrk

@michaelbrewer no. It only searches parameters defined by the template.

Awesome a good start :)

Nice @BrunoQuaresma i tested it how, only problem is that requires exact match, so for git_repo urls you have to do

owner:me param:"git_repo=https://github.com/microsoft/vscode-remote-try-go"

But it would be nice to do a contain search:

owner:me param:"git_repo=*vscode-remote-try-go"

@michaelbrewer I can reopen this?
#12695

@Emyrk possibly. If there is no concerns with performance.

Visually having an option to select additional fields would be great.

Search and filtering is useful for looking across an entire team, group or organization

@michaelbrewer I closed this at the time as it was not needed for the original purpose.

I can reopen this if it solves your use case

My use-case is the ux of when you have 2 or more workspaces stopped or listed on the dashboard. Users would not know which workspace is for which work.

Generally workspaces are linked to a repo. So showing the repo url or short name in list would help.

Filtering could help. But updating the list view would help more.

Got it. If updating the list view to see parameters is the better approach, I would rather not expand the filtering at this time.

I want to avoid adding it to the filter as it adds inconsistency in the other filter params. As it would be the only filter term to support *. Which is confusing.

Search by repo name implies there's a repo provided during checkout and enforces a one-repo-per-workspace development model that doesn't work so well if you're trying to use the same environment to work on multiple related repos. That's not a huge issue, but it's something to be aware of when looking at filtering options including "by repo."

for collections of repos, users creating a workspace should name it clearly. But short lived workspaces or tasks that can operate on a single repo having access to fields to filter on helps, as a workspace could have a number of custom parameters. like a custom parameter for a collection of repos to be checked out all at once for a specific project