doc: move doc to ci readme

This commit is contained in:
MarcoFalke 2020-06-06 21:52:46 -04:00
parent fa880773b4
commit fad6720891
No known key found for this signature in database
GPG Key ID: CE2B75697E69A548
2 changed files with 34 additions and 21 deletions

View File

@ -1,18 +1,4 @@
# The test build matrix (stage: test) is 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
# apt-get to install build dependencies. This guarantees that the tester is
# using the same versions as Gitian, so the build results are nearly identical
# to what would be found in a final release.
#
# In order to avoid rebuilding all dependencies for each build, the binaries
# are cached and re-used when possible. Changes in the dependency-generator
# will trigger cache-invalidation and rebuilds as necessary.
#
# These caches can be manually removed if necessary. This is one of the very
# Travis caches can be manually removed if necessary. This is one of the very
# few manual operations that is possible with Travis, and it can be done by a
# Bitcoin Core GitHub member via the Travis web interface [0].
#

View File

@ -1,12 +1,8 @@
## ci scripts
## CI Scripts
This directory contains scripts for each build step in each build stage.
Currently three stages `lint`, `extended_lint` and `test` are defined. Each stage has its own lifecycle, similar to the
[Travis CI lifecycle](https://docs.travis-ci.com/user/job-lifecycle#the-job-lifecycle). Every script in here is named
and numbered according to which stage and lifecycle step it belongs to.
### Running a stage locally
### 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.
@ -36,3 +32,34 @@ To run the test stage with a specific configuration,
```
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`.
If no `FILE_ENV` has been specified or values are left out, `00_setup_env.sh`
is used as the default configuration with fallback values.
It is also possible to force a specific configuration without modifying the
file. For example,
```
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 re-used when possible. Changes in the dependency-generator will
trigger cache-invalidation and rebuilds as necessary.