Open simonz130 opened 3 years ago
@nicoleczhu FYI
I think this is trickier than it seems.
1) what should the bot do when the title has changed? A natural implementation would be to update the label accordingly. Then we'll need to keep track of the timeline of streams of events. This comes with certain engineering cost.
2) Let's say the bot is implemented correctly, then the team will loose a capability of assigning label freely. I can imagine cases where a PR have a title of fix
, but actually the type should be feature request
.
There are several repos in GoogleCloudPlatform using https://github.com/bcoe/conventional-release-labels. If auto-label could support this use case (and the "breaking change" labeling), we could switch these repos onto auto-label.
I'm not sure if that action provides guidances towards Takashi's still-valid questions, but my thought: apply a type:
label if one is not set.
By adding where something is missing, the title becomes a way to set a sensible default. If someone has a need to make changes, they can edit the title and label and will learn that doing so is necessary.
Thanks for stopping by to let us know something could be better!
Is your feature request related to a problem? Please describe. We want to track the work we do in PRs by types (doc fixes, new features, bug fixes, etc. across all the repos our team works.
Describe the solution you'd like If both conventional commits bot and auto-label are enabled on the same repo, I want each PR to be auto-labeled based on conventional commits description of the PR. For example, new PRs with title "feat: XXX" will be auto-labeled as "type: feature request".