Conversation
|
I like it, although I'm sure it will give an error like in expressjs/expressjs.com#1553 |
|
Right, default token perms are read on prs I think it needs this update |
|
I still think it wouldn't work, we tried that in expressjs/expressjs.com#1557 and it didn't work. The only way we believe might work, although we haven't tested it yet, is by creating a token with the permissions as attempted in expressjs/expressjs.com#1642. |
|
Ah, it's the permission model for forks mucking that up in the linked issue. See the docs for GH_TOKEN perms, there's a note about this at the bottom. I'll push an update to allow this to run based on PRs from forks. |
|
After looking into this, idk that there's a safe way to do this tbh. We can use The original PR works as long as folks aren't opening PRs based on forks, but creating branches here in the repo. A github bot or github app might be the safest way to do this, can edit the PRs w/o having elevated permissions in a workflow file that can be altered by PRs coming from forks. TIL: the permission model of GHA is pretty wild |
this should allow the default token to have enough perms to label issues, even if the PR is coming from a fork.
9aecbfd to
b8896c2
Compare
|
EDIT: We decided not to make the name change in one of the TC meetings. |
|
due to permission issues, I don't think it's a good idea to add it, it will only create unnecessary noise about the workflow failing |
|
Yeah, I think I agree. Safety first! @jonchurch want to close? |
|
I'm going to close it, but feel free to reopen it. |
Related to #296 (comment)
Will label any PR that touches the adr dir w/
ADRlabel