--template does not work with --web when creating pull request

Describe the bug

The template query parameter is not added to the URL regardless of whether the template exists or not.

gh version 2.52.0 (2024-06-24)
https://github.com/cli/cli/releases/tag/v2.52.0

Steps to reproduce the behavior

gh pr create --base <base_branch> --head <fork_branch> --template <template> --repo <repo> --web

Expected vs actual behavior

I expect the template query parameter to be added to the URL. Even if the template does not exist in the repository because you may want to select an org-wide central pull request template. For example, swiftlang has such a template for pull requests to compiler-aligned release branches.

Yeh this also looks like it is a problem for issue create --template <template> --web.

Do you think we should validate the value provided here and error if it doesn't exist, or just pass it on regardless? I think for the most part looking at the code right now we generally just say "ok if you say so" when opening via --web.

Hi William!

It would be helpful to not error unless it can be verified that the template does not exist on both the repository and org levels. We at swiftlang share an org-wide template for pull requests to release branches across many compiler-aligned repositories, and a lot of these repositories in turn have their own custom default templates. gh pr create behaves such that any repository-level templates shadow org-wide ones (e.g. they are not shown in the interactive dropdown), so --template release.md --web would be a convenient way for us to tap into the org-wide template without having to manually insert the query parameter. Thanks!

Hmmmm, is there any chance that one of the repositories with shadowed templates is public. That doesn't seem like desirable behaviour, I'd like to look into it!

Sure, we’re open source. https://github.com/swiftlang/swift is an example. To be clear, it is the org-wide template that is shadowed or supplanted by repository templates.

That doesn't seem like desirable behaviour

This behavior is apparently analogous to the one explicitly specified for issue templates. I can see how this could’ve been an informed decision, though: A shared template is one use case for org-wide templates. Another one is a default template that only kicks in when a repo doesn’t have any of its own.

@AnthonyLatsis

I'm sorry @AnthonyLatsis, maybe it's late in a hot day in my office but I'm finding myself confused, sorry for being a bit dense.

Here's my understanding of your situation:

You have templates in https://github.com/swiftlang/.github for the org e.g the PR release template.
You have repositories that have their own PR templates that shadow the org level ones e.g. for the swift repo.
When you run gh pr create you are only offered the template from the repository, similar to what the docs say about issues[1]
It's possible to use an org level template via the browser ?template= query param, which is why you want this feature

If a repository has any files in its own .github/ISSUE_TEMPLATE folder, including issue templates or a config.yml file, none of the contents of the default .github/ISSUE_TEMPLATE folder will be used.

Is my understanding correct?

Looking at the queries for gh pr create via GH_DEBUG=api I don't believe we could do a verification step because we would not be given information about the org templates which seems to be what you want.

What I think "isn't desirable" behaviour is that you can create PRs from templates via the browser that you can't do via the API, or at least not via the information the API gives you for templates (since the template is just used to create a PR body that you can edit).

All good, I appreciate your mindfulness.

Is my understanding correct?

Yes. But I’m only really asking for --template <template> --web to work. The part about offering org templates in the CLI sounds like a larger topic that would benefit from more feedback because there are reasonable use cases for both hiding and not hiding them.

I don't believe we could do a verification step

Totally fine with me. My point in this regard was that if exhaustive verification is an option, it would probably make sense to do so to guard against typos in template names and such.

because we would not be given information about the org templates

Hm. Then how come gh pr create offers org templates when there are no repo templates?

Hm. Then how come gh pr create offers org templates when there are no repo templates?

The API reflects the rules as written in the docs, serving the repo templates when they exist and otherwise falling back to the org templates.

You can see in the two GH_DEBUG=api gh pr create snippets below that in the first case there are two repo templates and in the second case just one org template. Well, you can't tell from the API where they come from but you can see the org template here and the commit where I removed the repo templates here.

* Request at 2024-07-18 18:59:47.558489 +0200 CEST m=+4.439145959
* Request to https://api.github.com/graphql
> POST /graphql HTTP/1.1
> Host: api.github.com
> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
> Authorization: token ████████████████████
> Content-Length: 211
> Content-Type: application/json
> Graphql-Features: merge_queue
> Time-Zone: Europe/Amsterdam
> User-Agent: GitHub CLI 2.53.0

GraphQL query:
query PullRequestTemplates($name:String!$owner:String!){repository(owner: $owner, name: $name){pullRequestTemplates{filename,body}}}
GraphQL variables: {"name":"test-repo","owner":"williammartin-test-org"}

< HTTP/2.0 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
< Content-Security-Policy: default-src 'none'
< Content-Type: application/json; charset=utf-8
< Date:
< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
< Server: GitHub.com
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< Vary: Accept-Encoding, Accept, X-Requested-With
< X-Accepted-Oauth-Scopes: repo
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
< X-Github-Request-Id: FBF5:211A64:1C6EC5:1CB3A4:66994A02
< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a
< X-Oau
< X-Ratelimit-Limit: 5000
< X-Ratelimit-Remaining: 5000
< X-Ratelimit-Reset: 1721325560
< X-Ratelimit-Resource: graphql
< X-Ratelimit-Used: 10
< X-Xss-Protection: 0

{
  "data": {
    "repository": {
      "pullRequestTemplates": [
        {
          "filename": "pull_request_template.md",
          "body": "FOOBAR\n"
        },
        {
          "filename": "lol.md",
          "body": "lol\n"
        }
      ]
    }
  }
}

* Request to https://api.github.com/graphql
> POST /graphql HTTP/1.1
> Host: api.github.com
> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
> Authorization: token ████████████████████
> Content-Length: 211
> Content-Type: application/json
> Graphql-Features: merge_queue
> Time-Zone: Europe/Amsterdam
> User-Agent: GitHub CLI 2.53.0

GraphQL query:
query PullRequestTemplates($name:String!$owner:String!){repository(owner: $owner, name: $name){pullRequestTemplates{filename,body}}}
GraphQL variables: {"name":"test-repo","owner":"williammartin-test-org"}

< HTTP/2.0 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
< Content-Security-Policy: default-src 'none'
< Content-Type: application/json; charset=utf-8
< Date: Thu, 18 Jul 2024 17:00:36 GMT
< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
< Server: GitHub.com
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< Vary: Accept-Encoding, Accept, X-Requested-With
< X-Accepted-Oauth-Scopes: repo
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Github-Media-Type: github.v4; param=merge-info-preview.nebula-preview; format=json
< X-Github-Request-Id: FC10:7E8C:151601:1550B8:66994A31
< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a
< X-Oauth-Scopes: gist, read:org, repo, workflow
< X-Ratelimit-Limit: 5000
< X-Ratelimit-Remaining: 5000
< X-Ratelimit-Reset: 1721325560
< X-Ratelimit-Resource: graphql
< X-Ratelimit-Used: 15
< X-Xss-Protection: 0

{
  "data": {
    "repository": {
      "pullRequestTemplates": [
        {
          "filename": "release.md",
          "body": "A release template\n"
        }
      ]
    }
  }
}

Ah, I see. Thanks for clarifying!

Acceptance Criteria

PRs

When I create a PR with gh pr create --template filename.md --web
Then my browser is opened with the PR creation URL containing the query param template=filename.md

Issues

When I create a PR with gh issue create --template filename.md --web
Then my browser is opened with the Issue creation URL containing the query param template=filename.md

Note that since the web flow can allow for templates that are shadowed to be referenced, we cannot validate the value of the template flag.

Note that gh pr create --template filename.md without the --web flag will validate the value of the flag, because it is used for the contents of the body which are provided in the URL. However, since the template is used locally to form the body, it's not expected that if you select Continue in browser that it would contain the template=filename.md query param.

Note you cannot currently provide --body and --template, so it's correctly not possible to end up with both body and template in the URL as query params.

@Kyle-Ye

Hi William, sorry for this delay. No objections from me here, thanks.

cc @Kyle-Ye

Navigation Menu

Repository navigation

`--template` does not work with `--web` when creating pull request #9325

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Acceptance Criteria

PRs

Issues

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

--template does not work with --web when creating pull request #9325

Description

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Activity

williammartin commented on Jul 18, 2024

AnthonyLatsis commented on Jul 18, 2024

williammartin commented on Jul 18, 2024

AnthonyLatsis commented on Jul 18, 2024

williammartin commented on Jul 18, 2024

AnthonyLatsis commented on Jul 18, 2024

williammartin commented on Jul 18, 2024

AnthonyLatsis commented on Jul 19, 2024

williammartin commented on Jul 23, 2024

Acceptance Criteria

PRs

Issues

AnthonyLatsis commented on Sep 12, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`--template` does not work with `--web` when creating pull request #9325