This message was deleted.

Is there an open ticket for this? Or is this considered correct behaviour?

Sorry, could you give a little more context here? I’m not quite understanding the issue

Hey @Jacob Gold! Thanks for getting back to me. I have create a sample project to demonstrate the issue. I have a project here called graphite-pr-templates this repo has 1 PR template called OPTIONAL_PR_TEMPLATE. The docs for PR templates are here and it says

The logic mimics GitHub's for the most part

What happened: 1. When I create a PR using github's web interface I do not see a PR template: PR 2. When I create a PR using

gt stack submit

I see: a.

Edit body

which shows the non-default PR template b.

Skip

which uses the non-default PR template What I expect: Because there is no default PR template in this project I would expect no pr template

Ah, I see now — seems like we are incorrectly handling a single "optional" template in a

PULL_REQUEST_TEMPLATE

 folder the same as a template with the

pull_request_template.md

 filename.  Filed a ticket; thanks for clarifying!

Do you have SLA's for requests like this? Its blocking a project we have ongoing at Block

We don't have tight SLAs yet — we're still quite a small operation with lots to build — but we have recently started prioritizing fixes/features for customers on our enterprise plan!

I think you can change the line https://github.com/withgraphite/graphite-cli/blob/main/apps/cli/src/lib/utils/pr_templates.ts#L16 to be

(templateFiles.length === 1 && templateFiles[0].match(/pull_request_template.md$|pull_request_template.txt$/i) !== null)

and this should do it. Full disclosure, I don't do Javascript and I am unable to get

yarn build

to work but I think this would work

Hi, haven't had the chance to make this change yet, but will see if we can get that done soon for you!

Hey! Any news on this one?

it did! let me know if it works as expected for your case.

Looks like release 1.0.5 hangs when you select no-template with this configuration

Hey, we identified the bug and pushed a fix! look out for it in the next CLI release