LLVM forks may use GitHub Actions as well as the upstream projects,
but they do not necessarily follow the same development processes.
Disable automatic issue labeling for forks, so that it does not
interfere with downstream repo automation.
Details
- Reviewers
bader tstellar asl - Commits
- rG84f2ef2f2953: Disable issue labeler in LLVM forks
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Question for reviewers: is there any place we can document this, so that new GHA workflows use this line in future?
@tstellar can you please submit this patch for me? I don't have merge rights. Please, use alexander.batashev@intel.com as email.
@tstellar, this is common problems for all GitHub action being added to llvm-project.
Last week new workflow is added - https://github.com/llvm/llvm-project/blob/main/.github/workflows/llvm-bugs.yml.
It looks like it sends notification about newly opened issues to mailing list. I suppose once we pull this change to our repository, this workflow will send notifications about new issues in our repository as well. Right?
@alexbatashev fixed similar issues in the past (see https://reviews.llvm.org/D112801), but I think we need a solution for the more generic problem - most of GitHub Action workflows (if not all of them) must be applied to llvm-project only and turned off for forked repositories.
It's better to fix such problems before workflows are landed to llvm-project.
The action will run, but the notifications won't be sent, because the forked repos won't have the necessary secrets to send the email.
@alexbatashev fixed similar issues in the past (see https://reviews.llvm.org/D112801), but I think we need a solution for the more generic problem - most of GitHub Action workflows (if not all of them) must be applied to llvm-project only and turned off for forked repositories.
It's better to fix such problems before workflows are landed to llvm-project.
I think the best way to catch this is with a pre-commit test, that would be easier if were using pull requests, but maybe we can do something with Phabricator. Absent of that, then it's going to have to be caught by reviewers. If you are maintainer a fork and running into this problem a lot, I would suggest you create a Herald rule so that you are added as a reviewer on all workflow updates.