Open peaceiris opened 3 years ago
Hi, there.
Thank you @peaceiris for suggesting this.
This is an automated comment created by the peaceiris/actions-label-commenter. Responding to the bot or mentioning it won't have any effect.
Hi, there.
Thank you for suggesting documentation improvement.
This is an automated comment created by the peaceiris/actions-label-commenter. Responding to the bot or mentioning it won't have any effect.
I have suggestions for 2 possible ideas on how to restructure the file handling, which both have benefits but also disadvantages.
Perhaps it could be worth it to split up issues, PRs and discussions into separate files under a label-commenter
folder (i.e. .github/label-commenter/issue.yml
for issue-related comments).
issue
, pr
and discussion
sections used for each label.Maybe giving each label a own Markdown file could be the way to go. The settings could then be applied through YAML frontmatter, allowing pretty much the same level of control you currently have + some more.
Files would be (similar to the previous idea) be located in a label-commenter
folder inside the .github
one to keep it clean.
Example file named spam.md
:
---
allowed: # List of types this action should reply to
- issue
- pull_request
- discussion
# Used to "close", "open", "lock" or "unlock"
action: 'lock'
reason: 'spam' # Used when "lock" is set as action
# Settings to exclude Header/Footer
exclude_header: false
exclude_footer: false
---
## 🔒 LOCKED
This {{ type }} has been **locked** <!-- Maybe a new "{{ type }}" placeholder returning the type? (Issue, Pull request or Discussion) -->
Reason: Spam.
A dedicated _header.md
and _footer.md
could be used to apply header and footer to the comments.
allowed
list and save.:
f.e. supported in file names?
If I had to choose would I honestly go with the second option.
Those are interesting. But we should consider using the YAML anchor/alias at first.
labels:
- name: locked (spam)
labeled:
issue:
body: &locked_spam_body |
This issue has been **LOCKED** because of spam!
Please do not spam messages on this project. You may get blocked from this repository for doing so.
action: close
locking: lock
lock_reason: spam
pr:
body: *locked_spam_body
action: close
locking: lock
lock_reason: spam
discussion:
body: *locked_spam_body
locking: lock
lock_reason: spam
When we check a rendered body with GitHub Flavored Markdown, the yq
and grip
are useful.
yq e '.labels[10].labeled.pr.body' .github/label-commenter-config.yml
[The documentation label] was added. Thank you for suggesting documentation improvement.
When you add a new section, do not forget to update the Table of Contents.
[The documentation label]: https://github.com/peaceiris/actions-label-commenter/issues?q=label%3Adocumentation
yq e '.labels[10].labeled.pr.body' .github/label-commenter-config.yml | grip -
Splitting file looks interesting but I won't do that. I am sure that the current single YAML file approach is enough simple in the viewpoint of usability and maintainability.
Fair enough. Just thought it could be an interesting approach but there are obvious drawbacks and issues with it.
Maybe we can get another better approach in the future, so I will keep that in mind. Thank you!
Looking back at this after a relatively long time, I still have a good feeling about using separate markdown files for the different label actions, tho now I think about a slightly different approach.
You would still have own markdown files, but the main YAML configuration would now be used to define them.
Imagine the following files:
.github/label-commenter/issue-enhancement.md
{{ header }}
Thank you @{{ author }} for suggesting an improvement to this project!
{{ footer }}
.github/label-commenter/pr-enhancement.md
{{ header }}
Thank you @{{ author }} for proposing an improvement through a pull request!
{{ footer }}
.github/label-commenter-config.yml
comment:
header: Hi, there.
footer: "\
---\n\n
> This is an automated comment created by a GitHub Action.\n
> Replying or mentioning the bot has no effect."
labels:
- name: 'enhancement'
labeled:
issue:
template: '.github/label-commenter/issue-enhancement.md'
pr:
template: '.github/label-commenter/pr-enhancement.md'
The main configuration, including actions such as opening or closing an issue/PR would remain in the main configuration file, but content to comment would be out-sourced to those markdown files to use.
Placeholders such as {{ header }}
and {{ footer }}
would exist that would get replaced with their respective values from the config alongside any other supported placeholders...
Maybe, if that is wanted by others could a {{ config.<path.to.option> }}
placeholder be considered to allow others to define custom values inside the main configuration?
This would keep the main configuration a lot cleaner because even with that YAML anchor/alias thing is it not the best to look at.
All this is up to you of course.
Discussed in https://github.com/peaceiris/actions-label-commenter/discussions/445
Discussed in https://github.com/peaceiris/actions-label-commenter/pull/487#issuecomment-898109094
More generic placeholders for specific values
Right now do I need to use
{{ issue.user.login }}
,{{ pull_request.user.login }}
or{{ discussion.user.login }}
to achieve the same thing for issues, PRs and discussions respectively, which is getting the username of the person that created the issue, PR and/or discussion.This is somewhat annoying to have and I would like to propose some more generic/common placeholders to use, which would use different keys depending on the type.
{{ author }}
- Name of who created the Issue, PR or Discussion.{{ labeler }}
- Name of who labeled the Issue, PR or Discussion.{{ id }}
- The id of the Issue, PR or Discussion. (Maybe? Can't think of a good use-case here)