The baseline version calculations was assuming the minor release would
always be 0.
(cherry picked from commit d93363a0e803a9fb2889ff03237f4e93aacf0108)
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.
(cherry picked from commit 2836d8edbfbcd461b25101ed58f93c862d65903a)
There is more space available on /mnt (~56G) than on / (~30G), and we
are starting to see some of the CI jobs run out of disk space on Linux.
(cherry picked from commit 1a6426067fb33a8a789978f6e229108787a041be)
This was broken by d25022bb689b9bf48a24c0ae6c29c1d3c2f32823, 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
d25022bb689b9bf48a24c0ae6c29c1d3c2f32823.
(cherry picked from commit 792d928e15aa30c8b686eff465598ceea0b03891)
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.
(cherry picked from commit d25022bb689b9bf48a24c0ae6c29c1d3c2f32823)
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.
(cherry picked from commit 4b34558f43121df9b863ff2492f74fb2e65a5af1)
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.
(cherry picked from commit 2193c95e2459887e7e6e4f9f4aacf9252e99858f)
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 5c150e7eeba9db13cc65b329b3c3537b613ae61d.
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 reverts commit aa04d2b78bbbfef213d860876948b934ab18b1aa.
Meant to push this to my fork and did not realize I was on main and not
a separate branch.
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.
These cause test build failures on Windows.
This reverts the following commits:
57ca74843586c9a93c425036c5538aae0a2cfa60
d06ae33ec32122bb526fb35025c1f0cf979f1090
* 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.
