Use github wf to add module labels for PR based on file changes

[pseudo-nymous]

Description

Testing adding labels to PR based on file changes.

Following files were changed:
.github/labeler.yml
.github/workflows/label-pull-request.yml
help/my_file.txt
lucene/analysis/my_file.txt
lucene/benchmark/my_file.txt
lucene/core/my_file.txt
lucene/core/src/java/org/apache/lucene/util/hnsw/my_file.txt
lucene/luke/my_file.txt
lucene/queryparser/my_file.txt

[pseudo-nymous]

For testing, we are using pull_request trigger.

For apache/lucene repo, we would be using pull_request_target trigger. This is required for write access needed to add labels to PR.

[msokolov]

It seems that this would assign labels corresponding to different modules? I haven't seen such labels before, and I'm not sure if they are in active use, but it seems harmless and maybe useful to have them. I wonder if you could think of a way to assign a "milestone" label corresponding to the target branch of the commit?

[pseudo-nymous]

Yes, it assigns labels based on files they touch. We already had labels and requirement for this bot was raised here: apache#13897. I think it will be really useful.

I'll think of a way to assign milestone label based on the branch. It is doable.
Do we have a tags for that available already? Can you share more details on this?

[msokolov]

ah, ok -- the basic idea is we want to label (issues? PRs? both?) with milestones corresponding to Lucene releases. I think milestone is a special github field that is not just a label, and I'm not sure if it can have multiple values. If it can have multiple values, I guess it should be tagged according to all the branches with which it is associated: otherwise (single-values) we want the value to be the lowest numbered release that includes a change. A wrinkle is that typically the release doesn't yet exist when the issue is created, so we need to infer what it is going to be. For example a change might be committed to branch_10x, but the milestone would be 10.2 since that is the next anticipated release. Although - in theory there could be a 10.1.1 if we had a bugfix release, but IMO it would make sense to target the milestone at the next minor "point" release since I think this is what humans do today. As I write this, I don't know how it would be possible since the bot would have to know the release history, but ... maybe?

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the [email protected] list. Thank you for your contribution!