https://issues.apache.org/jira/browse/ARROW-10156

I think that dev_cron.yml isn't suitable.
Jobs in it run periodically.

How about using pull_request_target instead like https://github.com/actions/labeler#create-workflow ?

I agree @kou that dev_cron is not suitable atm and I though about a new flow. However, looking at the current jobs there, I think that they can all be migrated to a different on, since they can all be triggered by events, instead of a schedule.

So, my plan was to PR a migration of that dev_cron to be triggered by events, like you suggest. Does this make sense?

Do you want to change on in dev_cron.yml?
I don't think that it's a good idea. If we don't use schedule, it's not CRON.

How about creating a new workflow file such as .github/workflows/dev_pull_request.yml or something and putting only this job to the new workflow file?

Other existing jobs (jira-link and title-check) can be migrated to pull_request_target from schedule but we need to change .github/workflows/dev_cron/*.js logic. We can work on it as a follow-up task.

@jorgecarleitao I will be very happy to relinquish my role as github label admin (as I'm sure the other Rust committers will too). Thanks for working on this.

@kou, Thanks for the suggestion. I have moved the content to another place and added the on accordingly.

FYI @lidavidm (lang-java) and @romainfrancois (lang-R), since both of you are also tagging PRs with github labels.

@kszucs What do you think about this file name (dev_labelar) ?

We organize the gha configurations based on "language" and event. Based on that we have the option to name it dev_pull_request_target.yml but the pull_request_target event name is so misleading that I'd rather keep dev_labeler.yml since it's much more descriptive. Once we have more actions triggered on this event we can find a better name.

OK.
I'll merge this.