Since we moved to a Docker-in-Docker setup, CI jobs sometimes fail due
to the Docker VM dying with 'context cancelled' errors. This is currently
not recognized as a spurious failure, which leads to the job not being
automatically restarted. This patch fixes that.
This commit only adds a test job with the new logic since this workflow
triggers on workflow_run, which means that the changes need to be on
`main` before they can be tested. Once this is tested to work properly,
I'll make it the default definition for the workflow.
Running `ninja docs-libc-html` produces content in
{build_dir}/libc/docs, not
{build_dir}/docs. Presubmit jobs for "Test documentation build" were
failing as
a result of commit 97f94af356 ("[Github] Upload built docs as artifact
from
test build docs job (#118159)")
Link: #118159
Link: #117220
This patch makes the test documentation build job upload the docs that
have been built as artifacts. This makes it much easier to take a peek
at the resulting documentation rather than just being able to see that
it builds.
This patch adds a Github action that runs whenever changes to the libc++
Docker images are pushed to `main`. The action will rebuild the Docker
images and push them to LLVM's container registry so that we can then
point to those images from our CI nodes.
After a recent Github Actions runner policy change [1], the version of
Xcode included in the macos-14 image went from Xcode 16 to Xcode 15,
breaking our build bots.
This moves the bots to the macos 15 (public preview) image, which
contains Xcode 16.
Also, adjust an UNSUPPORTED annotation that was incorrectly targeting
macos 13.7 when it should have been targeting a version of AppleClang.
[1]: https://github.com/actions/runner-images/issues/10703
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
This change attempts to shift the libc++ builders over to new backend
infrastructure that allows running an arbitrary container for the
libc++ job.
This has been a long time in the making, and support from github
and gke is finally at the point where it's possible (hopefully).
This change should also demonstrate another important property:
No Downtime Upgrades.
If this goes well, we'll be able to test the upgrade as a part
of the PR process, and then commiting it to main should (ideally)
not break anything.
This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.
---------
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
This is instead of pushing directly. Creating a pull request is slightly
more work for the release manager, but it is more secure as we no longer
need a secret with write access to the www-releases repo.
The actions/checkout step will clear the current directory, so we need
to checkout the sources first so that the downloaded artifacts won't be
deleted.
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
This gets us the full list of users with commit access to
llvm/llvm-project rather than the list of people in the llvm-committers
team. This will ensure we are able everyone to track everyone with
commit access in case they receive access some other way.
When bringing up a new cross compiler from scratch, we build
libunwind/libcxx in a setup where the toolchain is incomplete and unable
to perform the normal linker checks; this requires a few special cases
in the CMake files.
We simulate that scenario by removing the libc++ headers, libunwind and
libc++ libraries from the installed toolchain.
We need to set CMAKE_CXX_COMPILER_WORKS since CMake fails to probe the
compiler. We need to set CMAKE_CXX_COMPILER_TARGET, since LLVM's
heuristics fail when CMake hasn't been able to probe the environment
properly. (This is normal; one has to set those options when setting up
such a toolchain from scratch.)
This adds CI coverage for these build scenarios, which otherwise seldom
are tested by some build flow (but are essential when setting up a cross
compiler from scratch).
This patch sets the timeout of the code formatting job to 30 minutes.
The job is currently failing in specific circumstances and needs to be
reworked, but as a temp hack, change the timeout to 30 minutes so that
we can catch these jobs before they hit the Github Actions timeout limit
of six hours.
Somewhat (hackily) alleviates #79661 slightly.
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
This patch decouples macOS CI testing from BuildKite, which makes the
maintenance of macOS CI easier and more accessible to all contributors.
Right now, the macOS CI is running entirely on machines owned by the
LLVM Foundation with only a small set of contributors having direct
access to them. In particular, updating these machines is currently
a very time-consuming manual process that requires taking the machines
offline, and using Github-provided instances makes that an order of
magnitude easier.
The story for performing back-deployment testing still needs to be
figured out, so for now we are retaining some jobs under BuildKite.
This workflow produces a list of users that should be moved to the LLVM
Triagers team. An admin will review the list and then manually move
people to the LLVM Triagers Team.
I've also added some documentation to the Developer Policy about the
Triage Role.
See
https://discourse.llvm.org/t/rfc2-new-criteria-for-commit-access/77110
for more details.
Currently the formatter only runs for the main branch, which prevents
the formatter from running for stacked PRs, which have to target user
branches instead of main.
This patch bumps the CI container LLVM version to 18.1.8. This should've
been bumped a while ago, but I just noticed that it was out of date.
This also allows us to drop a patch that we manually had to add as it is
by default included in v18.
Previously, #77219 added a `python_version` parameter for the Github
Actions CI Ninja-based build tests. This is necessary to run component
tests on different Python versions, as is currently done by the only
user of this parameter, the [Libclang Python bindings
test](https://github.com/llvm/llvm-project/blob/main/.github/workflows/libclang-python-tests.yml).
The parameter is missing from the concurrency group of the
workflow, meaning that starting the workflow with two different Python
versions immediately cancels one of them, as pointed out by
https://github.com/llvm/llvm-project/pull/77219#issuecomment-1937105822.
This change fixes that problem by making the Python version part of the
concurrency group key, and removes the superfluous concurrency group
from the calling workflow.
For reusable workflows, the called workflow cannot upgrade it's
permissions, and since the default permission is none, we need to
explicitly declare 'contents: read' when calling the release-sources
workflow.
Fixes the error:
The workflow is requesting 'contents: read', but is only allowed
'contents: none'.
We need a different attestation for each supported architecture, so
there artifacts all need to have a different name.
The upload step is run on a Linux runner, so no matter which
architecture's binary is being uploaded the runner.os and runner.arch
variables would always be 'Linux' and 'X64' and so we can't use them for
naming the artifact.
python3 wasn't able to see modules installed by pip, so we need to use
the setup-python action to ensure that the default pip and python3 both
use the same prefix.
See https://github.com/actions/runner-images/issues/10385
The old version in the llvm/actions repo stopped working after the
version variables were moved out of llvm/CMakeLists.txt. Composite
actions are more simple and don't require javascript, which is why I
reimplemented it as a composite action.
This will fix the failing abi checks on the release branch.
The old out-of-tree build configuration stopped working and in tree
builds are supported now, so we should use the in tree configuration.
The only downside is we can't run the tests any more, but at least we
will be able to test the build again.
If we pull from the release tag, then if there is a bug in one of the
actions on the release tag, then we can never do a build for that tag.
Pulling from main will allows us to fix bugs in the actions we use to
build the releases.
