CI: include automatic Pull Request Labeler

[pepe2k]

This adds GitHub CI action which makes use of 'Labeler', allowing automatic labeling of new PRs, based on the modified files paths.

Below labels are supported and more can be added later:

• 'target/*'
• 'target/imagebuilder'
• 'kernel'
• 'core packages'
• 'build/scripts/tools'
• 'toolchain'
• 'GitHub/CI'

For more information: https://github.com/marketplace/actions/labeler

[aparcar]

Looks good, can we label it based on branch, too?

[pepe2k]

Looks good, can we label it based on branch, too?

Not with this one, it only analyzes paths of modified files.
But what exactly do you have in mind, labels for target version the PR is for?

[Ansuel]

I also add this idea... but my idea was to create a bot with nodejs and host it instead of using actions
The idea was having more control and a bot assigning label was better than an actions...
(and also that would permit us to introduce useful command like /merged that would automatically flag the pr as merged and provide the hash in the git repo)

[Ansuel]

Not with this one, it only analyzes paths of modified files.
But what exactly do you have in mind, labels for target version the PR is for?

Think he was referring to pr specific to openwrt release

[pepe2k]

@Ansuel I'm fine with anything else but this solution exists now so why not use it till we have something more sophisticated?

[Ansuel]

@pepe2k sure i wanted to put some comments just to get some feedback of my idea...
(ideally the bot should be hosted on github servers)

But yhea ok for me for using actions to autolabel :D

[pepe2k]

sure i wanted to put some comments just to get some feedback of my idea...
(ideally the bot should be hosted on github servers)

Do you have a working PoC or some similar solution available somewhere to look at?

[Ansuel]

@pepe2k today i wasted some time with a PoC... (don't judge the following link ahahahah)

https://github.com/Ansuel/test-openwrt-webook
The bot is currently running on my local system.

Anyway in practice my solution is a custom github app.
Needs to be hosted but permit more flexibility than simple actions...

Current implementation assume an issue with for example

ath79: something

where ath79 is parsed with a regex (everything before : is used), we search if a label exist with that and assign it.

I also tested command. If you send a comment with /thanks the bot send a specific message.

Tell me what do you think about this.

(currently this is only implemented for issue but can be expanded and it's only a PoC)

[Ansuel]

(i'm turning off the local server... put here a message and i will reopen it ASAP)

[Ansuel]

New on this? @aparcar @pepe2k
Is the bot hosting viable? The implementation is very simple and much more flexible than a CI action

[pepe2k]

@Ansuel

Needs to be hosted but permit more flexibility than simple actions...

And needs to be hosted/maintained by someone.
We should limit amount of additional services and work around the project and focus on important parts.

Current implementation assume an issue with for example

ath79: something

where ath79 is parsed with a regex (everything before : is used), we search if a label exist with that and assign it.

I'm focusing on PRs here only, not issues which are much more complicated and might require a sophisticated solution.

I think this might not be reliable. You assume contributors will follow our patch submitting guide and provide correct prefixes - believe me, that's not always true. Solution based on a paths modified by commit/s in a selected PR is just simple and human-error prone.

I also think a simple regex on PR/issue title for labeling can also be done with actions.

Cheers,
Piotr

[Ansuel]

And needs to be hosted/maintained by someone.
We should limit amount of additional services and work around the project and focus on important parts.

This is my concern... Anyway the bot is so easy that once done it doesn't require that much changes...

I'm focusing on PRs here only, not issues which are much more complicated and might require a sophisticated solution.

The example was with issue just because it was easier to create tons of issue to develop the bot.
But it was just a proposal of a IMHO better solution

[pepe2k]

@Ansuel

This is my concern... Anyway the bot is so easy that once done it doesn't require that much changes...

Whenever I hear something like this, I run away 😏

But it was just a proposal of a IMHO better solution

I still fail to understand and see why it's better?

Cheers,
Piotr

[Ansuel]

I still fail to understand and see why it's better?

• Can be extended (command to automate some process like invalid pr/issue., invalid Sob, add relevant commit hash merged in master...)
• Can also be used with issue
• Check tags relevant to branch
• A bot that adds label instead of an action/a labeller from marketplace

[ynezz]

This adds GitHub CI action which makes use of 'Labeler', allowing automatic labeling of new PRs, based on the modified files paths.

LGTM as an immediate solution.

My gripe of such solution is, that we need to have this file included in our source code repository, which is going to pollute Git log history with a commits which are not related to the source code and each such commit/modification then triggers a build pipeline on our buildbot and build firmware images for all targets (~24 hours), so wasting a lot of resources.

Well, this is probably just an issue with our workflow and tooling around, so we should probably just start ignoring sole commits to a predefined directories like .github on buildbot.

And needs to be hosted/maintained by someone.

FYI you can use scheduled GitHub Action for that purpose, which is essentially "serverless" cron job. I'm for example using such feature to self-assign patches on our patchwork, it's running every two hours and doesn't need any additional infrastructure.

You assume contributors will follow our patch submitting guide and provide correct prefixes - believe me, that's not always true.

You can enforce such formalities with GH Actions.

I'm focusing on PRs here only, not issues which are much more complicated and might require a sophisticated solution.

Well, on GitHub every pull request is an issue, but not every issue is a pull request, so they share a lot. Using templates to encourage useful issues and pull requests should help a lot as well.

BTW GitLab is using machine learning for a classification based on a issue content.

[Ansuel]

Also OK for me as a solution for now but IMHO we should use specialized tools instead of a simple labeler :D

[Ansuel]

@pepe2k any news on this?

[pepe2k]

@Ansuel I will rebase and look again into this in next days, thanks for reminder!

[aparcar]

Looks good. I'd merge this

[pepe2k]

@aparcar done.
@ynezz thanks for all your comments,so far, I failed to find time to address them but will try again, this time harder (at least wasting buildbots resources is something I would like to look at)! :)

Hope it will do the job until we have something better™

Cheers,
Piotr