We should use the normal github.token for interacting with issues/PRs on
the repo, and separately pass the `--branch-repo-token` for creating the
branch in the llvmbot repo.
The `/cherry-pick` command needs `issues: write` to post a comment on
the issue. The `/branch` command also posts a comment, and also needs
`pull-requests: write` to open a PR.
This should fix the failure encountered at
https://github.com/llvm/llvm-project/issues/79253#issuecomment-1907850027.
The libclang python binding test CI job currently doesn't have any
restrictions on what branches it will run on when something is pushed
and also isn't restricted to the monorepo. This patch adds a branch
restriction for the push event, only running the CI job when something
is pushed to the main branch (and the path filter is met), and also adds
a filter to ensure that the job comes from a PR against the monorepo or
a push to a branch in the monorepo.
Revert "Revert #76246 and #76083"
This reverts commit 5c150e7eeb.
Adds a small fix that should properly disable the tests on Windows.
Unfortunately the original poster has not provided feedback and the
original patch did not fail in the LLVM CI infrastructure.
Modules are known to fail on Windows due to non compliance of the
C library. Currently not having this patch prevents testing on other
platforms.
This patch updates the paths in the PR labelling config for the MLGO
label. In particular, the path for the new mlgo-utils subfolder under
llvm/utils has been added and two other files that were missed in the
original introduction.
* Split out the lit release job and the documentation build job into
their own workflow files. This makes it possible to manually run these
jobs via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
This enables the libclang python binding test to check
the oldest version of Python supported in addition
to the normal python version.
It is important to check this for issue #76664, since
many new mainstream python type annotation features
and best practices are not compatible with older
versions of python.
Additionally, frustration around ever increasing
platform dependencies and versions has been raised.
This will help ensure that python maintains reasonable
backwards compatibility.
Adding this additional build step will increase the
run time, but this should always be minimal, since
the additional libclang compilation should see 100%
cache hit rate.
Issue #76664.
Fixes#76601.
This removes the entire modules testing infrastructure.
The current infrastructure uses CMake to generate the std and std.compat
module. This requires quite a bit of plumbing and uses CMake. Since
CMake introduced module support in CMake 3.26, modules have a higher
CMake requirement than the rest of the LLVM project. (The LLVM project
requires 3.20.) The main motivation for this approach was how libc++
generated its modules. Every header had its own module partition. This
was changed to improve performance and now only two modules remain. The
code to build these can be manually crafted.
A followup patch will reenable testing modules, using a different
approach.
Closes#75620
As I mentioned on the issue, this PR aims to hash-pin the CI
dependencies used on sensitive context -- i.e., they either are called
with write permissions, or are being used to build critical artifacts
like a release. In summary, this PR brings 3 changes:
1. Hash pin GitHub Actions called on sensitive context
2. Hash pin python dependencies used on sensitive context
3. Configure dependabot to automatically update those hashes
I'm further explaining the steps bellow.
The dependencies in format of GitHub Actions, I simply hash-pinned them.
I also made sure to keep the human-readable version as comments at the
same line.
At the
[release-tasks.yml](https://github.com/llvm/llvm-project/blob/main/.github/workflows/release-tasks.yml)
file, I've changed the installation method of some python dependencies
to install them considering their hashpinning. That required the
generation of a requirements file that had all the correct hashes, and
for that I used [pip-tools](https://pypi.org/project/pip-tools/2.0.0/).
While configuring dependabot, I set it to send a monthly PR updating all
the GitHub Actions, and a weekly PR to update any python dependency
required by
[/llvm/docs/requirements.txt](https://github.com/llvm/llvm-project/blob/main/llvm/docs/requirements.txt).
Let me know if you have any questions or concerns, I'd be happy to
clarify and help.
Thanks!
---------
Signed-off-by: Diogo Teles Sant'Anna <diogoteles@google.com>
I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to
notice it was disabled by default. Since we build libunwind by default
and ship it in the LLVM toolchain, it would seem to make sense that
libc++ and libc++abi rely on libunwind for unwinding instead of using
the system-provided unwinding library (if any).
Most importantly, using the system unwinder implies that libc++abi is
ABI compatible with that system unwinder, which is not necessarily the
case. Hence, it makes a lot more sense to instead default to using the
known-to-be-compatible LLVM unwinder, and let vendors manually select a
different unwinder if desired.
As a follow-up change, we should probably apply the same default to
compiler-rt.
Differential Revision: https://reviews.llvm.org/D150897Fixes#77662
rdar://120801778
This patch adds a configuration of the libc++ test suite that enables
optimizations when building the tests. It also adds a new CI
configuration to exercise this on a regular basis. This is added in the
context of [1], which requires building with optimizations in order to
hit the bug.
[1]: https://github.com/llvm/llvm-project/issues/68552
This is important to aid development of Python type annotations in the
libclang binding.
See https://github.com/llvm/llvm-project/issues/76664 for more details.
* Run on all pull requests and direct pushes.
* This makes use of the existing llvm-project-tests.yml recipe, which
will preload ccache from previous runs.
* Building libclang currently takes about 9mins when ccache is warm and
about an 1hr 20mins if it is cold using the standard GitHub ubuntu
runner.
* In the future, this could be broken into the following discrete steps
for clarity:
1. Build libclang dependency.
ninja -C build libclang
2. Run Python unit tests.
ninja -C build check-clang-python
* Followup changes will bring testing on older python versions and
static type checking.
Issue https://github.com/llvm/llvm-project/issues/76601.
Remove the redundant sccache cache key prefix.
This prefix is already added by the ccache action, which results in
cache keys like "sccache-sccache-ubuntu-...".
See the following source lines as proof:
2a51777f6f/src/restore.ts (L22-L23)
The "Setup ccache" step on macOS-11 builds takes between 15 to 20 mins,
whereas this step takes a less than 10 seconds on other runners. The
bulk of this time is spent at the "Install sccache" step, where brew
emits warnings like "Warning: You are using macOS 11." and "We (and
Apple) do not provide support for this old version...".
Bumping the version of macOS greatly decreases this cache setup time to
about 20 seconds. Furthermore, it seems like it is speeding up general
build times, too.
It appears that
https://github.com/actions/virtual-environments/issues/5900 has been
resolved or obsoleted, so I do not believe
we need to lock macOS to 11 anymore.
You can now pass the -use-cmake-cache option to test-release.sh and it
will use a predefined cache file for building the release. This will
make it easier to reproduce the builds and add other enhancements like
PGO or bolt optimizations.
---------
Co-authored-by: Konrad Kleine <konrad.kleine@posteo.de>
The runners-32 group is broken, for reasons...
The easiest fix is to move the jobs to runners-8.
(which needs to be renamed, because they're all actually 30 core
machines)
There are a few drive-by fixes:
- Since the combination RTTI disabled and exceptions enabled do not
work, this combination is prohibited.
- A small NFC in any fixing clang-tidy.
The code in the Buildkite configuration is prepared for using the std
module. There are more fixes needed for that configuration which will be
done in a separate commit.
For reasons unknown, the FIRST_TIMER and FIRST_TIME_CONTRIBUTOR states
don't come through on new user PRs, I have opened
https://github.com/orgs/community/discussions/78038 to see if that's my
mistake or GitHub's.
In the meantime, a possible workaround is to check that we have none of
the other states. If there's some bug that means the first time
associations aren't available in workflows, maybe the association will
be "NONE".
Also added a debug step to print that association so I can add it to the
linked report. I will remove this as soon as I have 1 example PR.
This patch sets the start revision to the merge base so that the c++
formatting action won't produce any diffs related to changes in main but
not in the PR branch. This also leaves a TODO to migrate over to the
--diff_from_common_commit option in git-clang-format once LLVM v18 is
released.
Add a pre-commit CI workflow for the experimental SPIR-V backend. This
action should only run when SPIR-V target or test files are modified.
The `codegen-spirv` tests don't run as part of `check-all` because the
SPIR-V backend is still experimental.
Depends on #73371 (for a green tree)
It seems the fail fast just doesn't strike the right balance.
It wastes too many resources, especially if a build is killed because
the machine it was running on got preempted.
Instead, we should simply not run any future jobs if a failure has
occured, while letting the already running jobs finish.
This includes some commonly needed information like how to add
reviewers.
This is implemented as a job before the labeler, so that on a new PR the
comment is added before there are any subscribers and only the author
gets a nofitication.
The labeler job depends on the greeter having run or having been
skipped. So if the PR wasn't just opened, or it's from a regular
contributor, the labeling still happens.
But we can be sure that when a greeting comment is left, it's the very
first thing we do.
Github actions has some quirks with how you use runner groups, labels,
names, etc... One of them is that groups can't "group" more than one set
of builders. To do that, you use the same name. So now we're specifying
the name.
We had a scheduled build on buildkite, we probably want something
testing head here as well.
Since this change just adds more tests, I think we can skip pre-commit review.
[skip ci]
This removes the Google hosted Linux buildkite builders. We have since
moved all of them over to github actions.
Follow up changes will be sent for android.
