This will cause the auto-labeler not to run on pull requests with more
than 10 commits. Usually larger pull requests like this are mistakes and
we want to avoid generating an excessive amount of notifications.
It may be possible for legitimate pull requests to have 10 or more
commits from people pushing fixup commits to addresss review comments.
However, these pull requests should already have the correct labels by
the time they grow to 10 commits.
The current regex for the `mlir:core` PR label is too accepting. It uses
`**` as a prefix for all paths, which allows any kind of directory
prefix to be inserted when matching. Combined with very common directory
suffixes such as `IR` and `Transforms`, it leads to many false positives
of being applied to PRs that do not touch MLIR core such as
https://github.com/llvm/llvm-project/pull/66520
This PR therefore changes the `mlir:core` labels to only include the
specified top-level directories if directly nested under either `lib`
for source files, or `include` for header files
- Only adds 'new issue' if no other label is added
(https://github.com/llvm/llvm-project/issues/65701)
- No not add labels if labels were already set
- Only add `foo` if there are no `foo:bar` label being added (although,
we don't use that yet)
Fixes#65701
This PR adds the paths the SPIR-V backend folks maintains. (Another
distince SPIR-V team exists, but only for the MLIR part (mlir-spirv).
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
The builtin concurrency functionality for the workflows will cancel a
pending job if there is another job from the same workflow running. For
the pr-subscriber job, this means that if multiple labels are added at
the same time, then some of the pr-subscriber jobs will be cancelled and
the PR will not have all the necessary mentions.
- Remove usages of the non-existent `ignore-forks` field, conditions in
jobs already exist to prevent the jobs from running in forks.
- Don't use variables in the `printf` format string. Use `printf
"..%s.." "$foo"`. ([SC2059](https://www.shellcheck.net/wiki/SC2059))
- Double quote variable expansion to prevent globbing and word
splitting. ([SC2086](https://www.shellcheck.net/wiki/SC2086))
- Prefer `[ p ] || [ q ]` as `[ p -o q ]` is not well defined.
([SC2166](https://www.shellcheck.net/wiki/SC2166))
- Consider `{ cmd1; cmd2; } >> file` instead of individual redirects.
([SC2129](https://www.shellcheck.net/wiki/SC2129))
- Use `$(...)` notation instead of legacy notation `...`.
([SC2006](https://www.shellcheck.net/wiki/SC2006))
- Use `./*glob*` or `-- *glob*` so names with dashes won't become
options. ([SC2035](https://www.shellcheck.net/wiki/SC2035))
- Refactor JavaScript code in certain workflows.
- Change workflow variable substitution style of some workflows to be
consistent with others.
This will reduce the number of notifications created when a pull request
label is added. Each team will only get a notification when their team's
label is added and not when other teams' labels are added.
We cannot use the default github token for labeling PRs, because this
will not trigger the PR Subscriber job. However, we weren't allowed to
use a different token via a secret, because secrets aren't allowed
in PR workflows.
The solution is to create two workflows, the first accepts the
pull_request_taget event extracts the PR number and then starts
the second workflow which adds the labels to the PRs.
This separation ensures that nothing malicious in the first workflow is
able to access the secret we use in the second workflow.
This new workflow will make it possible for people to subscribe to pull
requests based on the labels that are added. Labels will be added
automatically to the pull requests based on the modified files and each
label will be associated with a GitHub team that will be notified when
the label is added.
See
https://discourse.llvm.org/t/changes-to-pull-request-subscription-system/73296
Having test directories included for notifications sent out to these
teams seems like a decent idea. I don't think it should produce much
churn and it catches a couple cases like separately reviewed
pre-committed tests that aren't frequent but do exist.
The LLVM Dialect in MLIR, which the `mlir-llvm` team is supposed to
provide notifications for, is 98% not nested in a directory called LLVM
but rather LLVMIR. The former only contains some tests.
This should make PRs such as
https://github.com/llvm/llvm-project/pull/65508 add the team as
codeowner.
This also includes some files related to the Wasm binary and object file
format (which is technically distinct from the WebAssembly architecture,
but practically inseparable).
Using https://github.com/actions/labeler, this add a workflow to
automatically label PRs, in hope to reduce the work needed to triage new
PRs.
"new-prs-labeler.yml" has been seeded taking inspiration from the
CODEOWNERS file when there was an existing corresponding label on the
issue tracker.
This patch:
* Replaces `andymckay/labeler` which does not appear to be maintained by
github official solution
* Removes the closed issue workflow which was disabled a few years ago
and never fixed.
* Adds a few rules to add label based on PR title, hopefully that can
make triaging simpler. If that turns out to be useful, we can consider
adding more rules for backends, etc. We could technically also pattern
match the body of the issue but I'm concerned about trying to be _too_
clever.
The new system is only triggered on PR open so manual labels should not
be removed.
