[sdk] add optional display name and tag fields to project templates

[dschaller]

Description

Add support for two new fields to a project template block:

• DisplayName which is used to store a user friendly template name
• Tags which is used to store additional template metadata that is author-defined (e.g. team, environment, etc.)

This information will be used in the near-term within the console but longer term could also be used within the CLI.

Checklist

• I have run make tidy to update any new dependencies
• I have run make lint to verify my code passes the lint check
• I have formatted my code using gofumpt

• I have added tests that prove my fix is effective or that my feature works

Since this change only adds optional fields I didn't think tests would be worthwhile. I can add tests if it's thought they would be valuable.

• I have run make changelog and committed the changelog/pending/<file> documenting my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version

[pulumi-bot]

Changelog

[uncommitted] (2023-11-18)

Features

• [sdk/go] add optional display name and tag fields to project templates
  #14587

[dschaller]

quick note on this change - it looks like this used to be the case but is no longer true since templatesToOptionArrayAndMap is always called with showAll as true

[Frassle]

This information will be used in the near-term within the console but longer term could also be used within the CLI.

What's the exceptions for how these will work with the CLI?

DisplayName I guess would be used when listing the template in "new", but not clear what "tags" would be used for? Should that be used for the default value of stack tags? If its only for the service maybe it should be named more explicitly that it's only used by the cloud console?

[dschaller]

Yeah, display name could be used for listing out templates from the new command. Tags could also be used there acting as filters based on user input (e.g. new --tag env=production) or could be shown in the new list template subcommand.

[Frassle]

I suspect we'll get a few confusions over tags getting confused with stack tags but not sure there's much to help there.

[dschaller]

Makes sense how that could potentially be confusing since these tags are unique to the template and not necessarily the stack. I think there are a few options:

• Rename this field to something like TemplateTags which would help clarify where these are applied
• We could also propagate these tags to the stack upon creation / offer them as tag options during creation

What do you think @Frassle?

[cnunciato]

Agree the presence of tags could be confusing (are these stack tags? resource tags? actually they’re neither…), but templateTags seems redundant as a child of template.

How about labels? Still means basically the same thing, is sufficiently short to serve the CLI use case, and doesn’t overload a term we’re already using elsewhere. Also brings to mind GitHub labels, which users may find familiar and which serve a similar purpose (grouping, filtering).

categories could be another option — though might be a little more cumbersome to use at the command line.

I do think tags could be fine though. It’s probably worth pointing out that the other two kinds of tags we support (stack and resource) aren’t the same thing, either, so while introducing a third kind of tag might seem potentially confusing, at least it’d be consistent. I’ve definitely warmed up to this idea the more I’ve thought about it. 😊

[MitchellGerdisch]

How about something like metadata instead of tags or templateTags since it seems like it'll be a bit of a catch-all to transmit information to the NPW feature?

[cnunciato]

How about something like metadata

I like this too — it’s clear and leaves room for other kinds of metadata, beyond just tags/labels. Although it’s somewhat less clear to me how it’d work at the CLI.

[AaronFriel]

If I read the change here correctly, it'll be present under template:

template:
  tags: ...

That's pretty clear to me that this is for the template, and not anything else.

[dschaller]

I can swap to metadata if it'll be clearer - definitely don't want to cause confusion with overloading tags even more. My only concern with metadata is that it might be too broad where it might not be clear to user's how this metadata will translate to the template but it's likely not a huge issue.

Updated :)

[Frassle]

That CI error isn't due to your change but due to template updating and CI not handling it.

But kinda handy this didn't merge because I noticed while trying this out that "sdk/go/common/workspace/project.json" needs updating otherwise these templates refuse to load!

I think a couple of entries like:

"displayName": {
    "description":"Optional name to use as the display name of the template.",
    "type":[
        "string",
        "null"
    ]
},

and

"metadata":{
    "description":"Metadata is a map of key/value pairs to associate with the template.",
    "type":[
        "object",
        "null"
    ],
    "additionalProperties":{
        "type": "string"
    }

In the template/properties block covers it.

[dschaller]

thanks for catching that @Frassle! will update and push