54 releases (35 breaking)
0.36.1 | Nov 27, 2024 |
---|---|
0.36.0 | May 16, 2024 |
0.35.2 | Apr 25, 2024 |
0.34.3 | Aug 19, 2024 |
0.13.0 | Jul 22, 2021 |
#22 in #temp-dir
26,021 downloads per month
Used in 33 crates
(14 directly)
49KB
778 lines
🚧 IMPORTANT 🚧
Development of this repo has been moved 🚚.
The associated crate is corepc-node
Keeping this for a while in case we need backport, then we are going to archive this.
Bitcoind
Utility to run a regtest bitcoind process, useful in integration testing environment.
When the auto-download feature is selected by activating one of the version feature, such as 25_1
for bitcoin core 25.1, starting a regtest node is as simple as that:
// the download feature is enabled whenever a specific version is enabled, for example `25_1` or `24_0_1`
#[cfg(feature = "download")]
{
use bitcoincore_rpc::RpcApi;
let bitcoind = bitcoind::BitcoinD::from_downloaded().unwrap();
assert_eq!(0, bitcoind.client.get_blockchain_info().unwrap().blocks);
}
The build script will automatically download the bitcoin core version 25.1 from bitcoin core,
verify the hashes and place it in the build directory for this crate. If you wish to download from an
alternate location, for example locally for CI, use the BITCOIND_DOWNLOAD_ENDPOINT
env var.
When you don't use the auto-download feature you have the following options:
- have
bitcoind
executable in thePATH
- provide the
bitcoind
executable via theBITCOIND_EXE
env var
use bitcoincore_rpc::RpcApi;
if let Ok(exe_path) = bitcoind::exe_path() {
let bitcoind = bitcoind::BitcoinD::new(exe_path).unwrap();
assert_eq!(0, bitcoind.client.get_blockchain_info().unwrap().blocks);
}
Startup options could be configured via the Conf
struct using BitcoinD::with_conf
or
BitcoinD::from_downloaded_with_conf
Issues with traditional approach
I used integration testing based on external bash script launching needed external processes, there are many issues with this approach like:
- External script may interfere with local development environment 1
- Use of a single huge test to test everything 2
- If test are separated, a failing test may fail to leave a clean situation, causing other test to fail (because of the initial situation, not a real failure)
- bash script are hard, especially support different OS and versions
Features
- It waits until bitcoind daemon become ready to accept RPC commands
bitcoind
use a temporary directory as datadir. You can specify the root of your temp directories so that you have node's datadir in a RAM disk (eg/dev/shm
)- Free ports are asked to the OS. Since you can't reserve the given port, a low probability race condition is still possible, for this reason the process is tried to be spawn 3 times with different ports.
- The process is killed when the struct goes out of scope no matter how the test finishes
- Allows easy spawning of dependent processes like:
Thanks to these features every #[test]
could easily run isolated with its own environment.
Doc
To build docs:
RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --features download,doc --open
MSRV
The MSRV is 1.56.1 for version 0.35.*
Note: to respect 1.56.1 MSRV you need to use and older version of some dependencies, in CI the below dependency versions are pinned:
cargo update
cargo update -p tempfile --precise 3.3.0
cargo update -p log --precise 0.4.18
Pinning in Cargo.toml
is avoided because it could cause
compilation issues downstream.
Nix
For reproducibility reasons, Nix build scripts cannot hit the internet, but the
auto-download feature does exactly that. To successfully build under Nix the
user must provide the tarball locally and specify its location via the
BITCOIND_TARBALL_FILE
env var.
Another option is to specify the BITCOIND_SKIP_DOWNLOAD
env var and provide the
executable via the PATH
.
Alternatively, use the dep without auto-download feature.
Used by
Via bdk dependency
Via electrsd dependency:
Dependencies
~10–19MB
~253K SLoC