- 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
- Update the `actions/download-artifact` action to version 3.
- Use the major version of an action instead of specifying the minor or patch versions.
Differential Revision: https://reviews.llvm.org/D148327
This make sure the docs are always available and can be manually uploaded
if a later step fails.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D145996
Most forks won't have an LLVM_BUGS_KEY secret, so Mailgun will error out
with a missing key, and if forks do happen to have such a secret then we
still don't want to be getting emails to LLVM's mailing lists for
downstream forks.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D146235
- Update the GitHub workflow actions to their latest versions.
- Use the latest Node.js LTS release.
- Use the latest Ubuntu version for consistency across all workflows.
- The `set-output` command is deprecated and will soon be disabled (https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/) so use the new recommended way.
- Use the `$()` expressions for string interpolation instead of the deprecated backticks in Bash.
- Format the YAML files.
Differential Revision: https://reviews.llvm.org/D143015
libclc requires using cmake files to detect the LLVM installation instead
of llvm-config so we need to update our cmake invocation.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D142716
For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows. Explicitly
setting the default python to 3.10 fixes this problem.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D132280
Now that the symbol version for libclang.so changes for each release again,
we need to remove the symbol versions from the shared library in order
for the ABI checker to be able to compare with an older version of the
shared library.
