mark and unmark project as template

[mntlty]

Closes #7915

Tested:

1. command shows up in project commands

go run cmd/gh/main.go project -h
...
AVAILABLE COMMANDS
...
template:    Mark a project as a template

2. Mark a project as a template

go run cmd/gh/main.go project template 1 --owner "github"
# Marked project 104 as a template.

3. Unmark a project as a template with --undo

go run cmd/gh/main.go project template 1 --owner "github" --undo
# Unmarked project 104 as a template.

4. JSON format and addition of template field tested with the following commands

# mark project
go run cmd/gh/main.go project template 1 --owner "github" --format json | jq .

# view project
go run cmd/gh/main.go project view 1 --owner "github"  --format json | jq .

Caveats:

a. These mutations only work with org owned projects as called out in the docs. Attempting to mark a user project as a template returns an error

go run cmd/gh/main.go project view 1 --owner "@me"
GraphQL: Only projects owned by an Organization can be marked as a template. (markProjectV2AsTemplate)
exit status 1

b. I found a bug in the api response when formatting JSON - it returns the old value, rather than the new value for template. This isn't a CLI issue, it's a data issue which should be fixed.

[andyfeller]

@mntlty : what are you thoughts what would be better: as-is versus flags on gh project edit?

Though not a hard and fast rule, Primer CLI guidance has a couple thoughts on commands versus flags:

Use a flag for modifiers of actions
Avoid making modifiers their own commands

It has me thinking whether this should be a new flag under existing commands or not 🤷

[mntlty]

@andyfeller I don't think so, for two reasons:

1. discoverability - it's easier to find a subcommand than a flag. this format follows gh pr ready
2. balancing the two commands:
   a. this one doesn't work for users, so you could easily end up with a success in changing the project description, followed by a failure from the API, which would need to be messaged and is even harder for non-text based status codes.
   b. if we add a flag for template and a flag for unmark-template, we also need to add documentation saying that they are mutually exclusive, and add code to handle that clearly for users

what do you think?

[andyfeller]

Definitely want @samcoe and @williammartin opinion as the only corollary would be marking a repository as a template or not, which does exist with gh repo edit --template with code here 🤷

[mntlty]

marking a repo as a template is a very different concept from marking a project as a template. I think marking a pr as ready (i.e. from draft to ready and back) is a better comparison

[mntlty]

also noting that marking a repo as a template is part of the update mutation with its own inputs https://docs.github.com/en/graphql/reference/input-objects#updaterepositoryinput for repos, while this is a separate mutation similar to PR draft https://docs.github.com/en/graphql/reference/input-objects#convertpullrequesttodraftinput

[andyfeller]

🙌 Implementation on how marking templates or repos work aside, I mostly want to do due diligence while also supporting other GitHub product teams supporting their areas of responsibility. Thanks for letting me ask questions ❤️

[andyfeller]

Solid work, @mntlty, and thank you as always for enhancing the Projects experiences 💪