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
Since aa02002491 we weren't installing the
correct dependencies, and since 2836d8edbf
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.
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>
This patch adjusts the build process for building the toolchain for the
CI container to perform more rigorous perf-training for PGO,
particularly building the entirety of LLVM as that is what showed the
best results while benchmarking. This patch also splits the job into two
stages to avoid timeouts due to the large increase in buildtime. There
are a couple other hacks added in here to make things work that we can
do away with eventually once we're able to run jobs like this on more
powerful self-hosted runners.
This was broken by d25022bb68, which
caused the workflow to pass an empty string to ninja as the target. The
'all' target is probably not the right target for these tests, but this
is what the behavior was before
d25022bb68.
A recent comment modified the job to only run on the main branch, but
the formatting was slightly off, causing the job to not run. This patch
fixes the formatting so the job will run as expected.
Modifying a cherry-picked patch to fix code formatting issues can be
risky, so we don't typically do this. Therefore, it's not necessary to
run this job on the release branches.
This action is really just a wrapper around cmake and ninja. It doesn't
add any value to the builds, and I don't think we need it now that there
are reusable workflows.
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
Only the stage2-distribution target is built by default for the
stage2 distribution installation target. This means that we don't get a
BOLT optimized binary. This patch explicitly builds the
stage2-clang-bolt target before the distribution installation target so
that the clang binary is optimized before it gets installed.
This patch adjusts the Docker container intended for CI use to contain a
PGO+ThinLTO+BOLT optimized clang. The toolchain is built within a Github
action and takes ~3.5 hours. No caching is utilized. The current PGO
optimization is fairly minimal, only running clang over hello world.
This can be adjusted as needed.
This change adds a comment to the first PR from a new contributor that
is merged, which tells them what to expect post merge from the build
bots.
How they will be notified, where to ask questions, that you're more
likely to be reverted than in other projects, etc. The information
overlaps with, and links to
https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr.
So that users who simply read the email are still aware, and know where
to follow up if they do get reports.
To do this, I have added a hidden HTML comment to the new contributor
greeting comment. This workflow will look for that to tell if the author
of the PR was a new contributor at the time they opened the merge. It
has to be done this way because as soon as the PR is merged, they are by
GitHub's definition no longer a new contributor and I suspect that their
author association will be "contributor" instead.
I cannot 100% confirm that without a whole lot of effort and probably
breaking GitHub's terms of service, but it's fairly cheap to work around
anyway. It seems rare / almost impossible to reopen a PR in llvm at
least, but in case it does happen the buildbot info comment has its own
hidden HTML comment. If we find this we will not post another copy of
the same information.
The upload-artifact@v3 action is using Node 16, which is reaching EOL.
As a result, we are getting warnings prompting us to move our jobs over
to the latest version of upload-artifact.
