Skip to content
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

Jump to bottom

CI: Add a workflow to automatically label pull requests #10326

Closed
wants to merge 1 commit into from
Closed

CI: Add a workflow to automatically label pull requests #10326

wants to merge 1 commit into from

Conversation

dfandrich
Copy link
Contributor

The labeler language is quite restrictive right now so labels are added
quite conservatively, meaning that many PRs won't get labels when it's
"obvious" they should. It will still save some manual work on those
that it can label.

If this labeler were already running, it would have labeled this PR with "CI".

@github-actions github-actions bot added the CI Continuous Integration label Jan 20, 2023
@dfandrich
Copy link
Contributor Author

Actually, the action is running and it did add a CI label!

jay
jay reviewed Jan 22, 2023
View reviewed changes
.github/labeler.yml Outdated
- all: ['lib/*win32*']
- all: ['lib/curl_multibyte.*']
- all: ['lib/rename.*']
- all: ['Winbuild/**']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is case sensitive then it is 'winbuild' in lowercase. Also I think it should be added to the build tag if the labeler allows multiple tags to be applied to the same path.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done and done.

@dfandrich
CI: Add a workflow to automatically label pull requests
a101a1a 
The labeler language is quite restrictive right now so labels are added
quite conservatively, meaning that many PRs won't get labels when it's
"obvious" they should. It will still save some manual work on those
that it can label.
@dfandrich
Copy link
Contributor Author

I've added a few more documentation files & build paths.

jay
jay approved these changes Jan 24, 2023
View reviewed changes
Copy link
Member

@jay jay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see what happens.

@dfandrich dfandrich closed this Jan 24, 2023
@dfandrich dfandrich deleted the dfandrich/labeler branch January 24, 2023 06:30
jay referenced this pull request Jan 24, 2023
@dfandrich
CI: Add a workflow to automatically label pull requests
3eabedc 
The labeler language is quite restrictive right now so labels are added
quite conservatively, meaning that many PRs won't get labels when it's
"obvious" they should. It will still save some manual work on those
that it can label.
@dfandrich
Copy link
Contributor Author

The first workflow runs ran with GITHUB_TOKEN Permissions PullRequests: write but now they're running with PullRequests: read and failing with the error Error: HttpError: Resource not accessible by integration. The only difference that seems relevant is that the original PRs were on the curl repo but the PRs were on other people's repos. I wonder if that is the difference.

@dfandrich
Copy link
Contributor Author

I think that's it. According to the docs, Maximum access for
pull requests from public forked repositories: pull-requests=read so GitHub is downgrading the write access we want on other people's PRs. That makes this workflow almost useless.

@jay jay mentioned this pull request Jan 25, 2023
Closed
@jay
Copy link
Member

jay commented Jan 25, 2023

what about s/pull_request/pull_request_target like this guy

dfandrich added a commit that referenced this pull request Jan 25, 2023
@dfandrich
CI: Switch the labeler event to pull_request_target
de8cc21 
Otherwise, the action won't work on PRs from forked repositories
(#10326).
@dfandrich
Copy link
Contributor Author

I didn't notice that pull_request_target difference; I used the default template that was spit out for this action that had pull_request. I've submitted that change that, hopefully, will improve things. ReviewPad is considerably more powerful and can automate more things for us, but if people are hesitant about adding another app to the curl repo, and the labeler action merges my PR to add allofany patterns, this workflow will handle 90% of the labels I'd like to create ATM.

dfandrich added a commit that referenced this pull request Jan 25, 2023
@dfandrich
CI: Add a few more paths to the labeler config (#10326)
54189d8
dfandrich added a commit that referenced this pull request Jan 26, 2023
@dfandrich
CI: Add even more paths to the labeler config (#10326)
7d01a44
bch pushed a commit to bch/curl that referenced this pull request Jul 19, 2023
@dfandrich @bch
CI: Switch the labeler event to pull_request_target
563794e 
Otherwise, the action won't work on PRs from forked repositories
(curl#10326).
bch pushed a commit to bch/curl that referenced this pull request Jul 19, 2023
@dfandrich @bch
CI: Add a few more paths to the labeler config (curl#10326)
db6d3c9
bch pushed a commit to bch/curl that referenced this pull request Jul 19, 2023
@dfandrich @bch
CI: Add even more paths to the labeler config (curl#10326)
564fa71
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jay jay jay approved these changes

@cmeister2 cmeister2 Awaiting requested review from cmeister2

@mback2k mback2k Awaiting requested review from mback2k

Assignees
No one assigned
Labels
CI Continuous Integration
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@dfandrich @jay