boxtec
/
bitcoin
mirror of https://github.com/bitcoin/bitcoin
4
1
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '60d3e4b0cd'
${ noResults }
bitcoin/ci/test/00_setup_env_native_asan.sh

26 lines
1.4 KiB
Raw Normal View History Unescape

ci: Add environment files for all settings
5 years ago
#!/usr/bin/env bash
#
scripted-diff: Bump copyright headers -BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT- Commits of previous years: - 2021: f47dda2c58b5d8d623e0e7ff4e74bc352dfa83d7 - 2020: fa0074e2d82928016a43ca408717154a1c70a4db - 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
2 years ago
# Copyright (c) 2019-2022 The Bitcoin Core developers
ci: Add environment files for all settings
5 years ago
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
export LC_ALL=C.UTF-8
ci: only run USDT interface tests on CirrusCI As mentioned in #26571, the task running the USDT interface tests fail when run in docker. cc7335edc87c6ef34429b4df94f53973db520aac in #25528 added that the tests are run in a **VM** in Cirrus CI. Running them locally in docker containers might not work: - We use [bcc] as tracing toolkit which requires the kernel headers to compile the BPF bytecode. As docker containers use the hosts kernel and don't run their own, there is a potential for mismatches between kernel headers available in the container and the host kernel. This results in a failure loading the BPF byte code. - Privilges are required to load the BPF byte code into the kernel. Normally, the docker containers aren't run with these. - We currently use an untrusted third-party PPA to install the bpfcc-tools package on Ubuntu 22.04. Using this on a local dev system could be a security risk. To not hinder the ASan + LSan + UBSan part of the CI task, the USDT tests are disabled on non-CirrusCI runs. [bcc]: https://github.com/iovisor/bcc
2 years ago
# Only install BCC tracing packages in Cirrus CI.
if [[ "${CIRRUS_CI}" == "true" ]]; then
ci: Add missing linux-headers package to ASan task Otherwise the task will throw in skip_if_no_python_bcc. Also, adjust CI_CONTAINER_CAP for all needed permissions.
1 year ago
BPFCC_PACKAGE="bpfcc-tools linux-headers-$(uname --kernel-release)"
export CI_CONTAINER_CAP="--privileged -v /sys/kernel:/sys/kernel:rw"
ci: only run USDT interface tests on CirrusCI As mentioned in #26571, the task running the USDT interface tests fail when run in docker. cc7335edc87c6ef34429b4df94f53973db520aac in #25528 added that the tests are run in a **VM** in Cirrus CI. Running them locally in docker containers might not work: - We use [bcc] as tracing toolkit which requires the kernel headers to compile the BPF bytecode. As docker containers use the hosts kernel and don't run their own, there is a potential for mismatches between kernel headers available in the container and the host kernel. This results in a failure loading the BPF byte code. - Privilges are required to load the BPF byte code into the kernel. Normally, the docker containers aren't run with these. - We currently use an untrusted third-party PPA to install the bpfcc-tools package on Ubuntu 22.04. Using this on a local dev system could be a security risk. To not hinder the ASan + LSan + UBSan part of the CI task, the USDT tests are disabled on non-CirrusCI runs. [bcc]: https://github.com/iovisor/bcc
2 years ago
else
ci: Add missing linux-headers package to ASan task Otherwise the task will throw in skip_if_no_python_bcc. Also, adjust CI_CONTAINER_CAP for all needed permissions.
1 year ago
BPFCC_PACKAGE=""
export CI_CONTAINER_CAP="--cap-add SYS_PTRACE" # If run with (ASan + LSan), the container needs access to ptrace (https://github.com/google/sanitizers/issues/764)
ci: only run USDT interface tests on CirrusCI As mentioned in #26571, the task running the USDT interface tests fail when run in docker. cc7335edc87c6ef34429b4df94f53973db520aac in #25528 added that the tests are run in a **VM** in Cirrus CI. Running them locally in docker containers might not work: - We use [bcc] as tracing toolkit which requires the kernel headers to compile the BPF bytecode. As docker containers use the hosts kernel and don't run their own, there is a potential for mismatches between kernel headers available in the container and the host kernel. This results in a failure loading the BPF byte code. - Privilges are required to load the BPF byte code into the kernel. Normally, the docker containers aren't run with these. - We currently use an untrusted third-party PPA to install the bpfcc-tools package on Ubuntu 22.04. Using this on a local dev system could be a security risk. To not hinder the ASan + LSan + UBSan part of the CI task, the USDT tests are disabled on non-CirrusCI runs. [bcc]: https://github.com/iovisor/bcc
2 years ago
fi
ci: run USDT interface test in a VM Our CI tasks are run by CirrusCI in Docker containers in a Google Compute Engine based Kubernetes environment. These containers have limited capabilities - especially CAP_SYS_ADMIN is missing. See https://github.com/bitcoin/bitcoin/issues/23296#issuecomment-1024920845 We need elevated privileges to hook into the USDT tracepoints. We use a CirrusCI "compute_engine_instance" (a VM, not a container) where we have the required privileges. The ubunut-mininmal-2204-lts was choosen with debian-11 being an alternative. Both pack an outdated 'bpfcc-tools' package (v0.18.0) from 2020. This version prints warnings to stderr during BPF bytecode compilation, which causes our functional test runner to fail. This is fixed in newer verison. Until debian-12 or a newer Ubuntu release is avaliable as image in GCE (https://cloud.google.com/compute/docs/images/os-details), we use a third-party and untrusted PPA that releases up-to-date versions of the package. The official iovisor (authors of BCC) PPA is outdated too. An alternative would be to compile BCC from source in the CI. Co-authored-by: MacroFake <falke.marco@gmail.com>
2 years ago
test: set a name for CI Docker containers
5 years ago
export CONTAINER_NAME=ci_native_asan
ci: remove duplicate bsdmainutils from CI configs
1 year ago
export PACKAGES="systemtap-sdt-dev clang-16 llvm-16 libclang-rt-16-dev python3-zmq qtbase5-dev qttools5-dev-tools libevent-dev libboost-dev libdb5.3++-dev libminiupnpc-dev libnatpmp-dev libzmq3-dev libqrencode-dev libsqlite3-dev ${BPFCC_PACKAGE}"
ci: use LLVM/clang-16 in native_asan job Similar to #27298.
2 years ago
export CI_IMAGE_NAME_TAG=ubuntu:23.04 # Version 23.04 will reach EOL in Jan 2024, and can be replaced by "ubuntu:24.04" (or anything else that ships the wanted clang version).
ci: Add environment files for all settings
5 years ago
export NO_DEPENDS=1
export GOAL="install"
ci: Enable float-divide-by-zero check
1 year ago
export BITCOIN_CONFIG="--enable-c++20 --enable-usdt --enable-zmq --with-incompatible-bdb --with-gui=qt5 \
CPPFLAGS='-DARENA_DEBUG -DDEBUG_LOCKORDER' \
--with-sanitizers=address,float-divide-by-zero,integer,undefined CC=clang-16 CXX=clang++-16"