github
/
bitcoin
mirror of https://github.com/bitcoin/bitcoin
1
Fork 0
Code Releases Activity
40,317 Commits 5 Branches 310 Tags 5 GiB
C++ 64.1%
Python 20.1%
C 11.8%
M4 1.1%
Shell 1%
Other 1.8%
Go to file
Ava Chow 02c7fd8df4
Merge bitcoin/bitcoin#29483: test, ci: add --v1transport option, add --v2transport to a CI task 
ecc036c5d6 ci: add --v2transport to an existing CI job (Martin Zumsande)
3a25a575f0 test: ignore --v2transport for older versions instead of asserting (Martin Zumsande)
547aacff08 test: add -v1transport option and use it in test_runner (Martin Zumsande)

Pull request description:

  This suggests a strategy to run the functional tests with both v1 and v2 transport in the CI.

  **Status Quo:**
  There is both the global `--v2transport` option for the `test_runner.py` (not enabled by default), plus the possibility to specify `--v2transport` for particular tests, which is used for a handful of tests. Currently, when running `test_runner.py --v2transport`, these tests are run twice with the same `--v2transport` configuration, as has been noted in https://github.com/bitcoin/bitcoin/pull/29358#discussion_r1485626063, which is wasteful.

  **Suggested Change:**
  Fix this by adding a `--v1transport` option and using it in `test_runner.py`, so that irrespective of the global `--v2transport` flag, the  tests that run twice use v1 in one run and v2 in the other.
  Also add `--v2transport` to one CI task (`multiprocess, i686, DEBUG`).
  This means, that for each CI task, the majority of functional tests will run once using the global `--v2transport` option if provided, while a few selected tests will always run two times, once with `v1` and once with `v2`.

  **Rationale:**
  A simpler alternative would have been to remove all test-specific `--v2transport` commands from `test_runner.py` and just enable `--v2transport` option for a few CI tasks. I didn't do that because it would have meant that v2 would never be running in the CI for some platforms, and also be run a lot less locally by users and devs (who would have to actively enable the `--v2transport` option).

ACKs for top commit:
  tdb3:
    ACK for ecc036c5d6.
  achow101:
    ACK ecc036c5d6
  stratospher:
    ACK ecc036c.
  vasild:
    ACK ecc036c5d6

Tree-SHA512: 375b2293d49991f2fbd8e1bb646c0034004a09cee36063bc32996b721323eb19a43d7b2f36b3f9a3fdca846d74f48d8f1387565c03ef5d34b3481d2a0fe1d328
 		2024-03-11 09:22:12 -04:00
.github ci: Fix functional tests step for pull requests in Windows GHA job 2024-03-02 01:14:14 +00:00
.tx qt: Bump Transifex slug for 27.x 2024-02-07 09:24:32 +00:00
build-aux/m4 Revert "build: Fix undefined reference to __mulodi4" 2024-01-09 15:38:57 +01:00
build_msvc build, msvc: Cleanup `bitcoin_config.h.in` 2024-03-08 15:18:27 +00:00
ci ci: add --v2transport to an existing CI job 2024-02-29 13:50:30 -05:00
contrib Merge bitcoin/bitcoin#28960: kernel: Remove dependency on CScheduler 2024-03-08 20:58:04 -05:00
depends depends: fix BDB compilation on OpenBSD 2024-02-18 01:57:16 +01:00
doc doc: Wrap flags with code in developer-notes.md 2024-03-08 15:55:37 +07:00
share depends: Bump MacOS minimum runtime requirement to 11.0 2023-06-22 15:28:47 +00:00
src Merge bitcoin/bitcoin#29586: wallet: default wallet migration, modify inconvenient backup filename 2024-03-11 08:59:06 -04:00
test Merge bitcoin/bitcoin#29483: test, ci: add --v1transport option, add --v2transport to a CI task 2024-03-11 09:22:12 -04:00
.cirrus.yml ci: Skip git install if it is already installed 2024-02-16 16:06:45 +01:00
.editorconfig ci: Drop AppVeyor CI integration 2021-09-07 06:12:53 +03:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore build: produce a .zip for macOS distribution 2023-09-15 13:47:50 +01:00
.python-version Bump .python-version from 3.9.17 to 3.9.18 2023-10-24 18:51:24 +02:00
.style.yapf Update .style.yapf 2023-06-01 23:35:10 +05:30
CONTRIBUTING.md doc: Explain squashing with merge commits 2022-05-24 08:17:41 +02:00
COPYING doc: upgrade Bitcoin Core license to 2024 2024-01-10 16:29:01 -06:00
INSTALL.md doc: Added hyperlink for doc/build 2021-09-09 19:53:12 +05:30
Makefile.am tests: Add unit tests for bitcoin-tx replaceable command 2023-12-08 20:27:13 -05:00
README.md doc: Explain Bitcoin Core in README.md 2022-05-10 07:49:09 +02:00
SECURITY.md Update security.md contact for achow101 2023-12-14 18:14:54 -05:00
autogen.sh build: make sure we can overwrite config.{guess,sub} 2023-06-13 14:58:43 +02:00
configure.ac build: ignore deprecated-declaration warnings in objc++ macOS code 2024-03-07 13:07:17 +00:00
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

What is Bitcoin Core?

Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and graphical user interface, which can be optionally built.

Further information about Bitcoin Core is available in the doc folder.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core.

The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.