Add label based on PR (title, body, commits)

[SMoraisAnsys]

To help with PR triage, we could add an action that parses the PR title, body and commits (opt-in) to check for information allowing us to add default / custom labels. For example, automatically adding the "breaking" label, specifying the priority of the PR, specifying if it is associated to an inner tracking tool, ...

This action should be complementary to actions/labeler and not checking the modified files. The checking of commits is to retrieve git trailers in order to add labels.

Extend the idea proposed in #757

[MaxJPRey]

I am in favor of it. +1

[RobPasMue]

General question: what would happen in the following PR title and what do you have in mind?

feat: exposing new thermal model

Guided line of thought:

• Our current conventional commit parser should detect that it is an "enhancement". What else would you assign in terms of label to this title?
• With the above title it might be a bit difficult to see but... what if I renamed it to feat: exposing new thermal model example? Would you parse the PR title for words such as "example" to include the "documentation" label?
• What will the criteria be to determine the label?

I see the benefit but I have the feeling that we might end up having brittle actions since there is a lot of different paths that could go wrong. Not to mention the manual labelling that can happen - will it be overridden by your operations?

[SMoraisAnsys]

Thanks for your feedback, here are a few answers:

• AFAIK our current way of working is to leverage the branch title, not the PR title. I know some project where the branch name isn't following commit convention and often redirect to tickets in another repo. So parsing the title would be beneficial for them.
• I would only parse with the commit convention logic so checking the type (feat, chore, docs, ...), the scope (api, parser, cli, ...) and if there is a breaking change (use of !).

Also, I would like to leverage git trailers which could have been added in the commits of the PR.

[RobPasMue]

Aha - so you would limit yourself to the first segment of the commit:

feat(api)!: whatever content I am adding is a breaking change

From here you would only focus on feat(api)! - is that correct?

If that's the case, I'm completely for it!

[SMoraisAnsys]

Yeah and I mentionned the body of the PR to check for "trailers" like

Breaking Changes: ...

[RobPasMue]

Yeah and I mentionned the body of the PR to check for "trailers" like

Breaking Changes: ...

As long as there is a specific format (like conventional commits) that teams can align to if they want, all good. What I wouldn't suggest is to do some "manual" parsing of the content and label identification on our own. It has to be some standardized process and tool