2023-06-12 14:45:48 -07:00
|
|
|
#!/usr/bin/env bash
|
|
|
|
#===----------------------------------------------------------------------===##
|
|
|
|
#
|
|
|
|
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
# See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
#
|
|
|
|
#===----------------------------------------------------------------------===##
|
|
|
|
|
|
|
|
#
|
|
|
|
# This script performs a monolithic build of the monorepo and runs the tests of
|
|
|
|
# most projects on Linux. This should be replaced by per-project scripts that
|
|
|
|
# run only the relevant tests.
|
|
|
|
#
|
|
|
|
|
|
|
|
set -ex
|
|
|
|
set -o pipefail
|
|
|
|
|
|
|
|
MONOREPO_ROOT="${MONOREPO_ROOT:="$(git rev-parse --show-toplevel)"}"
|
2023-09-11 13:20:34 +02:00
|
|
|
BUILD_DIR="${BUILD_DIR:=${MONOREPO_ROOT}/build}"
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
INSTALL_DIR="${BUILD_DIR}/install"
|
2024-03-27 23:53:25 +01:00
|
|
|
rm -rf "${BUILD_DIR}"
|
2023-06-12 14:45:48 -07:00
|
|
|
|
|
|
|
ccache --zero-stats
|
2023-09-11 13:20:34 +02:00
|
|
|
|
|
|
|
if [[ -n "${CLEAR_CACHE:-}" ]]; then
|
|
|
|
echo "clearing cache"
|
|
|
|
ccache --clear
|
|
|
|
fi
|
|
|
|
|
2024-11-13 09:19:10 +00:00
|
|
|
function at-exit {
|
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
|
|
|
retcode=$?
|
|
|
|
|
2023-09-11 13:20:34 +02:00
|
|
|
mkdir -p artifacts
|
|
|
|
ccache --print-stats > artifacts/ccache_stats.txt
|
2024-11-13 09:19:10 +00:00
|
|
|
|
|
|
|
# If building fails there will be no results files.
|
|
|
|
shopt -s nullglob
|
2024-12-16 09:01:05 +00:00
|
|
|
if command -v buildkite-agent 2>&1 >/dev/null
|
|
|
|
then
|
2025-03-27 12:59:43 -07:00
|
|
|
python3 "${MONOREPO_ROOT}"/.ci/generate_test_report_buildkite.py ":linux: Linux x64 Test Results" \
|
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
|
|
|
"linux-x64-test-results" $retcode "${BUILD_DIR}"/test-results.*.xml
|
2024-12-16 09:01:05 +00:00
|
|
|
fi
|
2023-06-12 14:45:48 -07:00
|
|
|
}
|
2024-11-13 09:19:10 +00:00
|
|
|
trap at-exit EXIT
|
2023-06-12 14:45:48 -07:00
|
|
|
|
|
|
|
projects="${1}"
|
|
|
|
targets="${2}"
|
|
|
|
|
2024-11-12 13:24:44 +00:00
|
|
|
lit_args="-v --xunit-xml-output ${BUILD_DIR}/test-results.xml --use-unique-output-file-name --timeout=1200 --time-tests"
|
|
|
|
|
2023-06-12 14:45:48 -07:00
|
|
|
echo "--- cmake"
|
2024-03-27 23:53:25 +01:00
|
|
|
pip install -q -r "${MONOREPO_ROOT}"/mlir/python/requirements.txt
|
2024-06-08 16:23:17 +04:00
|
|
|
pip install -q -r "${MONOREPO_ROOT}"/lldb/test/requirements.txt
|
2024-11-13 09:19:10 +00:00
|
|
|
pip install -q -r "${MONOREPO_ROOT}"/.ci/requirements.txt
|
2024-03-27 23:53:25 +01:00
|
|
|
cmake -S "${MONOREPO_ROOT}"/llvm -B "${BUILD_DIR}" \
|
2023-06-12 14:45:48 -07:00
|
|
|
-D LLVM_ENABLE_PROJECTS="${projects}" \
|
|
|
|
-G Ninja \
|
|
|
|
-D CMAKE_BUILD_TYPE=Release \
|
|
|
|
-D LLVM_ENABLE_ASSERTIONS=ON \
|
|
|
|
-D LLVM_BUILD_EXAMPLES=ON \
|
|
|
|
-D COMPILER_RT_BUILD_LIBFUZZER=OFF \
|
2024-11-12 13:24:44 +00:00
|
|
|
-D LLVM_LIT_ARGS="${lit_args}" \
|
2023-06-12 14:45:48 -07:00
|
|
|
-D LLVM_ENABLE_LLD=ON \
|
|
|
|
-D CMAKE_CXX_FLAGS=-gmlt \
|
2023-11-25 09:55:32 +00:00
|
|
|
-D LLVM_CCACHE_BUILD=ON \
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
-D MLIR_ENABLE_BINDINGS_PYTHON=ON \
|
|
|
|
-D CMAKE_INSTALL_PREFIX="${INSTALL_DIR}"
|
2023-06-12 14:45:48 -07:00
|
|
|
|
|
|
|
echo "--- ninja"
|
2023-09-13 13:02:55 +02:00
|
|
|
# Targets are not escaped as they are passed as separate arguments.
|
2024-03-28 02:03:24 +01:00
|
|
|
ninja -C "${BUILD_DIR}" -k 0 ${targets}
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
|
|
|
|
runtimes="${3}"
|
|
|
|
runtime_targets="${4}"
|
|
|
|
|
|
|
|
# Compiling runtimes with just-built Clang and running their tests
|
|
|
|
# as an additional testing for Clang.
|
|
|
|
if [[ "${runtimes}" != "" ]]; then
|
|
|
|
if [[ "${runtime_targets}" == "" ]]; then
|
|
|
|
echo "Runtimes to build are specified, but targets are not."
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
echo "--- ninja install-clang"
|
|
|
|
|
|
|
|
ninja -C ${BUILD_DIR} install-clang install-clang-resource-headers
|
|
|
|
|
|
|
|
RUNTIMES_BUILD_DIR="${MONOREPO_ROOT}/build-runtimes"
|
|
|
|
INSTALL_DIR="${BUILD_DIR}/install"
|
|
|
|
mkdir -p ${RUNTIMES_BUILD_DIR}
|
|
|
|
|
|
|
|
echo "--- cmake runtimes C++26"
|
|
|
|
|
|
|
|
rm -rf "${RUNTIMES_BUILD_DIR}"
|
|
|
|
cmake -S "${MONOREPO_ROOT}/runtimes" -B "${RUNTIMES_BUILD_DIR}" -GNinja \
|
|
|
|
-D CMAKE_C_COMPILER="${INSTALL_DIR}/bin/clang" \
|
|
|
|
-D CMAKE_CXX_COMPILER="${INSTALL_DIR}/bin/clang++" \
|
|
|
|
-D LLVM_ENABLE_RUNTIMES="${runtimes}" \
|
|
|
|
-D LIBCXX_CXX_ABI=libcxxabi \
|
|
|
|
-D CMAKE_BUILD_TYPE=RelWithDebInfo \
|
|
|
|
-D CMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
|
|
|
|
-D LIBCXX_TEST_PARAMS="std=c++26" \
|
2024-11-12 13:24:44 +00:00
|
|
|
-D LIBCXXABI_TEST_PARAMS="std=c++26" \
|
|
|
|
-D LLVM_LIT_ARGS="${lit_args}"
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
|
|
|
|
echo "--- ninja runtimes C++26"
|
|
|
|
|
|
|
|
ninja -vC "${RUNTIMES_BUILD_DIR}" ${runtime_targets}
|
|
|
|
|
|
|
|
echo "--- cmake runtimes clang modules"
|
|
|
|
|
2025-03-25 19:38:33 +04:00
|
|
|
# We don't need to do a clean build of runtimes, because LIBCXX_TEST_PARAMS
|
|
|
|
# and LIBCXXABI_TEST_PARAMS only affect lit configuration, which successfully
|
|
|
|
# propagates without a clean build. Other that those two variables, builds
|
|
|
|
# are supposed to be the same.
|
|
|
|
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
cmake -S "${MONOREPO_ROOT}/runtimes" -B "${RUNTIMES_BUILD_DIR}" -GNinja \
|
|
|
|
-D CMAKE_C_COMPILER="${INSTALL_DIR}/bin/clang" \
|
|
|
|
-D CMAKE_CXX_COMPILER="${INSTALL_DIR}/bin/clang++" \
|
|
|
|
-D LLVM_ENABLE_RUNTIMES="${runtimes}" \
|
|
|
|
-D LIBCXX_CXX_ABI=libcxxabi \
|
|
|
|
-D CMAKE_BUILD_TYPE=RelWithDebInfo \
|
|
|
|
-D CMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
|
|
|
|
-D LIBCXX_TEST_PARAMS="enable_modules=clang" \
|
2024-11-12 13:24:44 +00:00
|
|
|
-D LIBCXXABI_TEST_PARAMS="enable_modules=clang" \
|
|
|
|
-D LLVM_LIT_ARGS="${lit_args}"
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
|
|
|
|
echo "--- ninja runtimes clang modules"
|
2025-03-21 12:39:47 -07:00
|
|
|
|
[clang][ci] Move libc++ testing into the main PR pipeline (#93318)
Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.
Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)
Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.
The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.
2024-05-28 02:25:15 +04:00
|
|
|
ninja -vC "${RUNTIMES_BUILD_DIR}" ${runtime_targets}
|
|
|
|
fi
|