-
-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
contributing: Add auto-labelling to pull requests #531
Conversation
I think this would be useful to have or at least try out in action even if it is limited e.g. to the currently existing labels (if we want to keep the number of labels low). |
We may try, otherwise we'll never find out... |
@nilason does this PR need to be updated since GH Actions are now in place? |
No, this is a separate feature, should work as is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments added inline...
af65037
to
dcf85d2
Compare
Rebased and updated to better reflect current list of labels. The labels I commented out |
3d11ad8
to
dcf85d2
Compare
PR rebased, but it needs more permissions:
|
Thanks! Updated, works now on a private test repo of mine. (Looks like it have to be merged before kicking in). |
I don't see any permissions in the YAML file, but I see them in the example in doc linked by @neteler. Any insights? What I'm asking is basically, do you expect the workflow to successfully run after merging it with the current configuration in terms of permissions?
That's definitively the case. |
I changed to
Yep. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some new suggestions to have this PR up to date with changes with the action used. I would really like this PR to come through soon, it would be quite useful for tidying up the backlog (that I started doing)
@neteler Just so you know, in this section it mentions that the action might fail one day at the time of a major version update of the action that would introduce breaking changes in the config, so that we might need to force it through while using the |
And for the different labels, and the old discussions about various small details, I think that it's overall quite adequate, docs is a good idea, since having details on html, css, JavaScript might be overkill. However, if is possible to make a distinction between docs, the content, and docs, the system/infrastructure around it, that might be a better solution than having things like "manual". Docs-only changes should be able to be merged more quickly without the same amount of programming-level code review. My stance is that it is already both hard to have contributors in open source and hard to have good docs in open source, so let's not leave out the contributions we could have. If we consider that documentation changes is often the first point of entry in contributing in open source, its even more important to offer a good experience to start with. Thus, when a PR would have docs (the content) only changes, if it's clearer and no mistakes, it could be merged expeditiously. Docs, as the infrastructure, could be like any other topic, and I think there is work on changing from manually creating HTML to markdown, so these extra categories will change in the mid-future. In conclusion, this PR, as a tool for us, should be fine tuned after usage, and it's our (changing) usage that dictates its requirements. We can't be that wrong with this. Our irritants will show us what to improve. |
Do I have the blessing to apply the suggestions I think are needed to unblock this PR? |
I'm sitting with it at this moment. |
Thanks @echoix for the suggestions, added them with new commit. |
May I suggest to merge this ASAP, this workflow may be fine-tuned or even dropped is not good enough. |
I was about to finish approving it and go for merging. Merging main into the PR branch wasn't explicitly needed. We have enabled the option to always show it, so it was a suggestion rather than a warning, and it helps to retrigger CI for older PRs, without having to close/open the PR (which would run the same outdated CI), and rather pull in some new code that might include CI changes. We'll see in 1h30+ if we can merge it then.. |
Discussion resolved now, and further tuning will be done at a later time
* GitHub: add auto-labelling to pull requests * add Markdown; add python/; update action version * use pull_request_target * update after review feedback * use docs label for docs * update for actions/labeler@v5 with added review suggestions --------- Co-authored-by: Markus Neteler <neteler@gmail.com> Co-authored-by: Edouard Choinière <27212526+echoix@users.noreply.github.com>
This adds auto-labelling to pull requests (related to #526).
It works with GitHub actions and add labels based on the PR's modified/added/deleted files location in repository.
This is a proposal, so if you find this approach appealing at all, I'm happy to receive suggestions for modifications.
Present proposal requires addition of some new labels.
The rules are stated in labeller.yml and as an example any modification in lib or include directory would add a
lib
label to the PR.