lit tests require commands FileCheck and not. They must be available in
the PATH.
This also guarantees that python3-psutil is installed in order to enable
more tests.
Fixes#64892.
I landed this format helper, but unfortunately, it didn't work because
of permissions, it could not add comments on a fork's PR. @cor3ntin
informed me there are fixes for this that you had worked on @tstellar -
but I didn't have time to read up on it too much. Can you explain what
changes are needed to get the action to be able to write comments on
fork's PR?
This helper will format python files with black/darker and
C/C++ files with clang-format.
The format helper is written so that we can expand it with new
formatters in the future like clang-tidy.
Avoid false positives by requiring space after `/branch` command so the
action won't trigger on diffs that include filenames like
`.../BranchProbabilityInfo.cpp`.
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.
- 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
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
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.
This change enables the LLDB project to begin experimenting with
pull-request workflows to help identify issues was we move toward
adopting pull requests.
Reviewed By: tstellar, JDevlieghere
Differential Revision: https://reviews.llvm.org/D155315
