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 397f1ce9ef 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 80b2aac2c6.
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.
It's subsumed by an order of magnitude more popular `vectorization` label that is applied for the same path patterns.
Statistics (issues and PRs together):
`vectorization`: 91 open, 91 closed
`vectorizers`: 8 open, 5 closed
All `vectorizers` usages has occurred in just the past 2 weeks, and likely by our bot.
The pattern for mlir:presburger was incomplete, and there was a typo for mlir:affine (was spelled `afine`)
Also group the MLIR pattern, this file would better be sorted but this deserves its own commit.
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.
The current regex for the `mlir:core` PR label is too accepting. It uses
`**` as a prefix for all paths, which allows any kind of directory
prefix to be inserted when matching. Combined with very common directory
suffixes such as `IR` and `Transforms`, it leads to many false positives
of being applied to PRs that do not touch MLIR core such as
https://github.com/llvm/llvm-project/pull/66520
This PR therefore changes the `mlir:core` labels to only include the
specified top-level directories if directly nested under either `lib`
for source files, or `include` for header files
- 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
