Add workflow to automatically label pull requests

[hashhar]

For starting with this will add the docs label to any changes under the docs tree.

We can eventually add more rules.
The end-goal is to use these labels to selectively run tests or run additional tests.

e.g. for docs the product tests don't make sense to run. Also for example if there are changes in Hive related code the tests:hive label could be added automatically to ensure all the Hive product test configs run.

In this PR no actions are being taken based on the label so nothing changes except triaging might be a little easier now.

[Praveen2112]

Can we have any test PRs which is labeled as doc based on this workflow ?

[findepi]

what is the value of the "pull_request_target" => ? association here?

guessing it it an empty map, consider:

Suggested change

	pull_request_target:
	pull_request_target: {}

[findepi]

also, shouldn't we limit this to types: [open]? let's allow humans to unlabel something, for example if only docs/READE is changed.

[mosabua]

Anything in the docs tree is docs related .. even if it is just the readme or the pom or whatever .. but yes, we should also allow unlabelling

[findepi]

just labeler should be fine (see ci.yml)

[findepi]

if we go with types:open, we should remove this as no longer applicable

[findepi]

any particular reason not to use the default location (.github/labeler.yml)?

[mosabua]

I am good with the idea and approach. Would be interested to figure out if this also updates the label if files change? E.g. a code PR does not have the label but then an update to some docs is added in a follow up push. Imho this should then add the docs label.. we can however merge and revise later.

Also I hope this does not add too much time to the build overall.

[mosabua]

Anything in the docs tree is docs related .. even if it is just the readme or the pom or whatever .. but yes, we should also allow unlabelling

[hashhar]

This was done in a different way in #9674

That has the benefit that it'll work correctly even if someone manually mislabels or files change after the PR is created.

[findepi]

@hashhar auto-adding docs label is still valuable eg for human consumption, even if what-to-test decision is determined differently (#9674)

[hashhar]

Fair point, I'll create a new one/re-open after verifying if it works even when changes are made to an already open PR.

[findepi]

after verifying if it works even when changes are made to an already open PR.

Do you think it's a must-have? it's not a must-have for me.

FWIW see labelling in https://github.com/apache/iceberg project: https://github.com/apache/iceberg/pulls/

[ebyhr]

e.g. for docs the product tests don't make sense to run.

I think we should add docs label when the PR contains docs change and it doesn't contain other changes if we want to use it for tests filter.

[hashhar]

I think we should add docs label when the PR contains docs change and it doesn't contain other changes

Should be possible by changing existing label config to:

docs:
  - all: ['docs/**']

if we want to use it for tests filter.

I think using labels for tests filtering has the downside that labels are applied after CI run has already been dispatched.
The way you implemented the docs check seems more robust.

IMO labels are for human consumption/informational. Test filtering should be as automatic as possible (like it is for docs-check).