Checking out a ref of the branch requires the remote to be the same as
the fork whereas setting it to be the commit SHA allows for us to avoid
changing the remote. This should fix the action not working on PRs made
from forks (essentially all of them).
This commit adds another step to the Github workflow that runs the code
formatting check to fetch through the merge base. This ensures that the
necessary history is present to find the changed files and also to run
clang-format over. This change massively increases the speed of the
action (~10 minutes down to ~2 minutes in most cases from my testing)
and also increases the reliability significantly.
There are currently a couple jobs that run on all forks of LLVM too (if
there is a PR opened, or in the case of the documentation builds, upon
pushing to main). This isn't desired behavior. This commit disables that
behavior, forcing the jobs to not run if they aren't running against
llvm/llvm-project or a PR against that repo.
This patch enables building the flang docs in Github actions to enable
rapid iteration in PRs and to catch docs build failures more easily
before merge/after merge. This patch currently doesn't fail for Sphinx
warnings, but the intention is to enable this functionality once the
flang docs are fixed to build without warnings after the transition to
Myst.
This is essentially a revert of
1ed710836a77a5a29f3649da87f9f3e8ae3aa086. It is safe to use the
pull_request_target event for pr-subscriber, because it does not
checkout any code from the pull request branch.
This is essentially a revert of
91fdb20915696ab955be0baea18b976717e370b9. It is safe to use the
pull_request_target event for new-prs, because it does not checkout any
code from the pull request branch.
We've gotten ~750 commits in the last 7 days. Upping the fetch depth to
2000 will make it more likely that PRs up to 2 weeks old will have
enough fetch history to find a common parent. This _might_ address some
of the failures we're seeing in the clang-format action where it cannot
find a common base commit.
This reverts commit 4aa12afb967bd7c5f051f3b72271f787f1a7538b.
This change introduced failures upon checking out the PR source code.
Pulling this out of tree while I investigate further.
This patch makes a couple changes to the PR code formatting check:
- Moves the `changed-files` action to before the checkout to make sure
that it pulls
information from the Github API rather than by running `git diff` to
alleviate some
performance problems.
- Checkout the head of the pull request head instead of the base of the
pull request
to ensure that we have the PR commits inside the checkout.
- Add an additional sparse checkout of the necessary LLVM tools to run
the action
to alleviate security problems introduced by checking out the head of
the pull
request. Only code from the base of the pull request runs.
- Adjust the commit references to be based on `HEAD` as Github doesn't
give
exact commit SHAs for the first commit in the PR.
This patch enables building the openmp documentation through Github
actions during PRs and at tip of tree to ensure that the documentation
builds and that there aren't any Sphinx warnings in a manner that
enables more rapid developer iteration without having to install
documentation tooling.
https://github.com/llvm/llvm-project/pull/69824 added libc build, but
missed the folder in ninja command, is causing failures.
ninja: fatal: chdir to 'docs-libc-html' - No such file or directory
ninja: Entering directory `docs-libc-html'
This patch adds the lld documentation to the documentation github
actions CI to automatically validate in PRs/at tip of tree that the docs
build and there aren't any Sphinx warnings. There is existing buildbot
coverage for the lld docs, but this much more convienient to use in
cases like PRs.
This patch adds support for building the libc docs in Github actions.
This eanbles easily diagnosing doc build failures/warnings in PRs and at
the tip of tree.
My previous commit 397f1ce9efb4eea1ee10fe4833f733b8c7abd878 switched up
the docs github action to use the GH API for pull requests. However,
this breaks the action when pushing to a branch as the Github API can't
provide diffs for commits. This patch fixes that by creating a local
checkout beforehand on push events for determining the changed files.
People are currently running into issues where the files-changed step
isn't able to find the merge base. This seems to happen more often on
very out of date branches. This patch side steps the issue by just
fetching the diff from the GH API.
This patch adds a step to the documentation Github action to build the
libc++ docs if they have changed. This enables easily diagnosing build
failures/warnings in PRs.
This patch adds the libunwind docs to the Github docs action which
enables easy triage of docs build failures in Github PRs. There is
already buildbot coverage of this configuration, but it is much less
convenient to use in PRs.
There still seem to be issues with the files changed step taking a
significant amount of time on PRs. This seems to be occurring on PRs
with one commit and not on PRs with more than one commit which is why I
didn't catch this nuance before. Either way, fetching an additional
commit seems to fix the issue. Requires a little bit of hackiness due to
the fact that you can't do math in the github actions variables.
Will be monitoring this over the next little bit to see if this actually
fixes the problem.
CI stuff is annoying sometimes.
This patch adds a step to build the lldb docs when they change to the
Github docs action, enabling easy triage of warnings/docs build failures
during the PR process.
This patch adds the clang-tools-extra docs to the Github CI job that
builds docs, enabling the ability to easily ensure the docs build
properly without warnings in PRs and at the tip of tree.
The SPHINX_OUTPUT_HTML and SPHINX_OUTPUT_MAN CMake flags are by default
set to ON/True in ./llvm/cmake/modules/FindSphinx.cmake, so we don't
need to set them true again within the CMake invocation.
This patches changes the docs action to run a fetch with a depth of the
number of commits in the PR (1 if we're just running against a push
event) which significantly increases the speed of the changed files
event. The changed files event goes from taking ~30m to ~3s without any
noticeable increase in fetch time.
This reverts commit 80b2aac2c671771d74bc5d7426f7bd4ffa0b8a8e.
I mistakenly assumed this job didn't also do python formatting
(should've grepped for more than just black in the python portion of
this script). Pulling it out for now to get python formatting working
again while the patch is iterated further.
Recently, support for building the LLVM documentation within Github
actions landed, allowing for easy testing of the docs both pre and post
landing. This patch extends that functionality to clang and adds in
additional support to the docs Github workflow to only build the docs
for the subproject whose documentation has been touched.
Currently the PR formatting job only runs clang-format. There isn't a
lot of utility in running it if there aren't any C/C++ changes as there
will be nothing to format. This isn't super noisy currently as the job
doesn't fail if there aren't any C/C++ changes, but it's a bit of a
waste.
In addition, this patch names the code formatting job "Check C++
Formatting" to make it clear that this job only checks C/C++ formatting
rather than Python formatting/other languages.
This allows running these quick checks faster than in our Buildkite
pipeline, which has much more latency. This will also avoid blocking the
rest of the testing pipeline in case the generated-files checks are
failing.
Currently this job fails when trying to install system dependencies as
the apt-get commands are not run with sudo, so they don't have the
appropriate permissions. This does not occur with act which is why it
wasn't caught in the first place. The change has been validated as
fixing the problem against my fork.
This patch adds in support for building the LLVM documentation through a
Github actions job. This enables catching documentation build failures
earlier and also more easily as the job failure will show up directly on
pull requests. The job currently only builds the documentation for LLVM,
but the plan is to extend it to also build the documentation for other
subprojects when appropriate (i.e., the docs files have changed),
starting with clang.
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.
