elements/ci
Tom Trevethan 13398037b6
set Wno-error for simplicity keep warning but dont error on it
fuzz test fixes

set -DPRODUCTION for simplicity in fuzz tests

set UNDEBUG for simplicity in fuzz tests

update wallet fuzz tests

update test script

fix msvc conversion issues

more msvc vector conversion fixes and substitution of boost libs

fix more hexstr calls

fix hexstr calls in init.cpp

default CMAKE_GENERATOR to Unix Makefiles

more span fixes

specify build bin directory

fix executable locations

fix fuzz tests for c11 and functional test fixes

fix fuzz test executable path

specify legacy wallet for elements functional tests

remove assertion for static initialization order issue

use elements fuzz corpus

print debug log on failure

use heap for blind and asset_blind

test: avoid disk space warning for non-regtest

feature_config_args.py incorrectly assumed that its testnet4 node
would not log a disk space warning.

0683b8ebf3 increased m_assumed_blockchain_size
on testnet4 from 1 to 11 GiB which triggers this bug on more
systems, e.g. a RAM disk.

Prevent the warning by setting -prune for these nodes.

Fix the same issue in feature_signet.py

Github-Pull: #32057
Rebased-From: 20fe41e9e83d510fd467f5a999d55a614b16ef89
2026-06-17 14:15:49 +01:00
..
lint Merge 6342348072 into merged_master (Bitcoin PR bitcoin/bitcoin#28076) 2025-11-06 11:27:08 +02:00
retry build: update retry to current version 2019-10-30 18:49:57 -04:00
test set Wno-error for simplicity keep warning but dont error on it 2026-06-17 14:15:49 +01:00
lint_imagefile ci: Switch to gcr.io mirror to avoid rate limits 2025-02-19 15:48:04 +01:00
lint_run_all.sh lint: Use consistent out-of-tree build for python and test_runner 2024-07-22 14:01:24 +02:00
README.md fix typos 2025-01-24 09:12:38 +08:00
test_imagefile ci: Fix macOS-cross SDK rsync 2023-08-16 10:30:50 +02:00
test_run_all.sh ci: move-only CI_CONTAINER_ID to 02_run_container.sh 2023-10-09 16:17:04 +02:00

CI Scripts

This directory contains scripts for each build step in each build stage.

Running a Stage Locally

Be aware that the tests will be built and run in-place, so please run at your own risk. If the repository is not a fresh git clone, you might have to clean files from previous builds or test runs first.

The ci needs to perform various sysadmin tasks such as installing packages or writing to the user's home directory. While it should be fine to run the ci system locally on your development box, the ci scripts can generally be assumed to have received less review and testing compared to other parts of the codebase. If you want to keep the work tree clean, you might want to run the ci system in a virtual machine with a Linux operating system of your choice.

To allow for a wide range of tested environments, but also ensure reproducibility to some extent, the test stage requires bash, docker, and python3 to be installed. To run on different architectures than the host qemu is also required. To install all requirements on Ubuntu, run

sudo apt install bash docker.io python3 qemu-user-static

It is recommended to run the ci system in a clean env. To run the test stage with a specific configuration,

env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'FILE_ENV="./ci/test/00_setup_env_arm.sh" ./ci/test_run_all.sh'

Configurations

The test files (FILE_ENV) are constructed to test a wide range of configurations, rather than a single pass/fail. This helps to catch build failures and logic errors that present on platforms other than the ones the author has tested.

Some builders use the dependency-generator in ./depends, rather than using the system package manager to install build dependencies. This guarantees that the tester is using the same versions as the release builds, which also use ./depends.

It is also possible to force a specific configuration without modifying the file. For example,

env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j1" FILE_ENV="./ci/test/00_setup_env_arm.sh" ./ci/test_run_all.sh'

The files starting with 0n (n greater than 0) are the scripts that are run in order.

Cache

In order to avoid rebuilding all dependencies for each build, the binaries are cached and reused when possible. Changes in the dependency-generator will trigger cache-invalidation and rebuilds as necessary.