Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR template support #47

Open
prakashbalaji opened this issue Oct 25, 2024 · 3 comments
Open

PR template support #47

prakashbalaji opened this issue Oct 25, 2024 · 3 comments

Comments

@prakashbalaji
Copy link

Hi,

Nice tool and helps a lot speed up developer workflow, thanks for making it available. Most of our repos have a PR template, do we have support for it already? Like honouring the template but adding the useful information about the stack at the bottom of the template.

-Prakash

@ZolotukhinM
Copy link
Collaborator

Thanks for the kind words!
For templates the thing is that here we're using commit message as the future content for created PRs. You could configure your git repo to use a template for commit messages and thus your PRs would comply with the expected template on the github. Would that be something that you could use instead? While it would be neat to be able to query the template directly from GitHub, I feel that interactions with everything else could get hairy, and additionally I don't think there is a programmatic way to query such templates from GH repos.

@prakashbalaji
Copy link
Author

Thanks @ZolotukhinM for the suggestion and it works well with a commit template. Not sure if there could be a way to add a placeholder markdown in the template to suggest where the stack-pr comment should be added so that it gives users some control over where to place the stack like at the top vs at the bottom of the template.

Screenshot 2024-11-06 at 9 07 09 AM

@ZolotukhinM
Copy link
Collaborator

That would complicate some other existing features (e.g. --keep-body which needs to update only the stack-pr comment, but not the actual description). It feels like this is not a critical thing to have and in some sense is a matter of taste, so I'd prefer to not add it at the potential expense of introducing problems into other features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants