Add wheel publishing in addition to existing source distribution
publishing of lit.
Fixes#63369. This also uses the exact fix proposed by @EFord36 in
#63369.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Since we have released Clang 16 is no longer actively supported. However
the FreeBSD runner is still using this, so some tests still guard
against Clang 16.
The recent change to split the PR code formatting job accidentally
misspelled the repository field when specifying the repository to fetch
the code formatting utils from. This patch fixes the spelling so that
the job does not throw a warning and clones the tools from the specified
repository.
I'm hoping this will fix the errors we've been seeing the last few days:
2024-03-19T20:44:07.4841482Z 2024/03/19 20:44:07 error signing scorecard
json results: error signing payload: getting key from Fulcio: verifying
SCT: updating local metadata and targets: error updating to TUF remote
mirror: invalid key
Actions triggered by pull_request_target events have access to all
repository secrets, so it is unsafe to use them when executing untrusted
code. The pr-code-format workflow does not execute any untrusted code,
but it passes untrused input into clang-format. An attacker could use
this to exploit a flaw in clang-format and potentially gain access to
the repository secrets.
By splitting the workflow, we can use the pull_request target which is
more secure and isolate the issue write permissions in a separate job.
The pull_request target also makes it easier to test changes to the
code-format-helepr.py script, because the version of the script from the
pull request will be used rather than the version of the script from
main.
Fixes#77142
It fixes a few rules that don't seem to be working and adding myself to a few paths where I've been contributing and can offer my review. Also minor sorting changes.
This reverts commit dec63221d56e8092557f29f1f2c127828d7521bb.
This probably needs more discussion before we can land it. The consensus
(from what I can gather) in https://discourse.llvm.org/t/rfc-clang-format-all-the-things/76614
is that we should be careful with version upgrades for consistency.
Bazel PRs aren't being tagged or auto assigned, so they're easily
missed, especially for those created by contributors w/o triage or
commit access.
I'm putting myself as the default auto reviewer, but only for the
purposes of making sure PRs don't get lost.
Since aa02002491333c42060373bc84f1ff5d2c76b4ce we weren't installing the
correct dependencies, and since 2836d8edbfbcd461b25101ed58f93c862d65903a
we must pass a custom token to github-upload-release.py for verifying
permissions.
This patch adds repository checks to the release-binaries workflow jobs.
People were observing that the job was running on a schedule in their
forks. This only happens on old forks, but those probably exist in great
number given how prolific LLVM is. This is also good practice anyways,
on top of solving the direct problem of these jobs running with the cron
schedule on people's forks.
Similar to #82200:
Add paths for SystemZ related changes to the PR labeler.
There is no pr-subscribers-backend:SystemZ team in the llvm org yet.
Much appreciated if some admin can help to create the team.
The default GitHub token does not have read permissions on the org, so
we need to use a custom token in order to read the members of the
llvm-release-managers team.
Now that the number of warnings in the flang sphinx build has come down
significantly, we can turn on warnings as errors in the sphinx build,
which is the default configuration in CMake.
This makes it so that the documentation test build workflow will run
when the workflow itself is changed. This makes it much easier to test
inside of PRs that modify the workflow.
When a backport request is made, the resulting pull request will have a
title like this:
<release branch>: <First line of HEAD commit for the branch>
And a body that says:
Backport <commit0> <commit1> ..
Requested By: <user>
