aboutsummaryrefslogtreecommitdiff
path: root/.appveyor.yml
AgeCommit message (Collapse)Author
2020-12-16Removed redundant git pull from appveyor config.Aaron Clauson
Github-Pull: #20506 Rebased-From: 2c69381f3de5091e103cb8bef299aba321503e7c
2020-12-16Adjusted msvc compiler and linker settings to remove optimisations that are ↵Aaron Clauson
causing sporadic ABI issues on Visual Studio updates. Tidied up debug and release configuration blocks in common project file to avoid duplication. Updated appveyor config to use latest Visual Studio 2019 image. Changed appveyor config file hash to use a new version of Qt pre-compiled binaries built for Visual Studio 2019 v16.8.1. Bumped vcpkg version to tag '2020.11-1' for binary caching feature. See #20392 for related discussion. Github-Pull: #20506 Rebased-From: 8b99e609e7da5dd3601e9214d8f869e96108fffe
2020-12-16This change to the appveyor CI config for msvc builds reverses a change ↵Aaron Clauson
introduced in #19960. It re-applies a setting to inform vcpkg to only build release vesions of the dependencies rather than the default of debug and release. It had been expected that the vcpkg manifest mechanism introduced in #19960 would do this automatically but it turns out not to be the case. Github-Pull: #20489 Rebased-From: fa18e7cbc5ea6aaba94dca4ebdc850c9db141f89
2020-11-15ci: Use the previous build worker image in AppVeyorHennadii Stepanov
This is a workaround as the recent Visual Studio 2019 image update breaks our builds.
2020-10-06Bump vcpkg commit ID to get new msys mirror listAaron Clauson
This fixes the appveyor CI job, see #20066. Currently the job fails because some of the vcpkg dependencies need to install msys2 and the hardcoded mirror in the vcpkg config is down. Vcpkg commit 76a7e9248fb3c57350b559966dcaa2d52a5e4458 adds new mirrors to the hardcoded list.
2020-09-29Update msvc build to use new vcpkg manifestAaron Clauson
The vcpkg tool has introduced a proper way to use manifests, https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/. This PR replaces the custom text file mechanism with the new manifest approach. It is planned that vckpg manifests will include the ability to version dependencies in the future. Dependency versions would solve a number of issues that currently require workarounds with the appveyor CI. Set vcpkg manifest version to 1 to avoid any perception it's related to any release or other version numbering.
2020-08-31Update the vcpkg checkout commit ID in appveyor config.Aaron Clauson
2020-08-30Set appveyor vm version to previous Visual Studio 2019 release.Aaron Clauson
Latest vm version has updated cmake and the berkeleydb vcpkg now fails to build.
2020-07-30Merge #18011: Replace current benchmarking framework with nanobenchWladimir J. van der Laan
78c312c983255e15fc274de2368a2ec13ce81cbf Replace current benchmarking framework with nanobench (Martin Ankerl) Pull request description: Replace current benchmarking framework with nanobench This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench ACKs for top commit: laanwj: ACK 78c312c983255e15fc274de2368a2ec13ce81cbf Tree-SHA512: 9e18770b18b6f95a7d0105a4a5497d31cf4eb5efe6574f4482f6f1b4c88d7e0946b9a4a1e9e8e6ecbf41a3f2d7571240677dcb45af29a6f0584e89b25f32e49e
2020-07-04Remove cached directories and associated script blocks from appveyor CI ↵Aaron Clauson
configuration.
2020-06-13Replace current benchmarking framework with nanobenchMartin Ankerl
This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench * Adds support for asymptotes This adds support to calculate asymptotic complexity of a benchmark. This is similar to #17375, but currently only one asymptote is supported, and I have added support in the benchmark `ComplexMemPool` as an example. Usage is e.g. like this: ``` ./bench_bitcoin -filter=ComplexMemPool -asymptote=25,50,100,200,400,600,800 ``` This runs the benchmark `ComplexMemPool` several times but with different complexityN settings. The benchmark can extract that number and use it accordingly. Here, it's used for `childTxs`. The output is this: | complexityN | ns/op | op/s | err% | ins/op | cyc/op | IPC | total | benchmark |------------:|--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|----------:|:---------- | 25 | 1,064,241.00 | 939.64 | 1.4% | 3,960,279.00 | 2,829,708.00 | 1.400 | 0.01 | `ComplexMemPool` | 50 | 1,579,530.00 | 633.10 | 1.0% | 6,231,810.00 | 4,412,674.00 | 1.412 | 0.02 | `ComplexMemPool` | 100 | 4,022,774.00 | 248.58 | 0.6% | 16,544,406.00 | 11,889,535.00 | 1.392 | 0.04 | `ComplexMemPool` | 200 | 15,390,986.00 | 64.97 | 0.2% | 63,904,254.00 | 47,731,705.00 | 1.339 | 0.17 | `ComplexMemPool` | 400 | 69,394,711.00 | 14.41 | 0.1% | 272,602,461.00 | 219,014,691.00 | 1.245 | 0.76 | `ComplexMemPool` | 600 | 168,977,165.00 | 5.92 | 0.1% | 639,108,082.00 | 535,316,887.00 | 1.194 | 1.86 | `ComplexMemPool` | 800 | 310,109,077.00 | 3.22 | 0.1% |1,149,134,246.00 | 984,620,812.00 | 1.167 | 3.41 | `ComplexMemPool` | coefficient | err% | complexity |--------------:|-------:|------------ | 4.78486e-07 | 4.5% | O(n^2) | 6.38557e-10 | 21.7% | O(n^3) | 3.42338e-05 | 38.0% | O(n log n) | 0.000313914 | 46.9% | O(n) | 0.0129823 | 114.4% | O(log n) | 0.0815055 | 133.8% | O(1) The best fitting curve is O(n^2), so the algorithm seems to scale quadratic with `childTxs` in the range 25 to 800.
2020-04-15Merge #18640: appveyor: Remove clcacheMarcoFalke
fac0c8db9f634ea7231fb0b6dc139ae0bda4a051 appveyor: Remove clcache (MarcoFalke) Pull request description: The build time without cache seems to be 47 minutes and with cache 46 minutes. Maybe we can save more time by not installing clcache. Top commit has no ACKs. Tree-SHA512: ce503641a465f5e49deb7aa6b566aaab5e567148c001704451891c49ba7ade3219ca788bc0d8e55565febb9aadd579e26894f6c03b99755eb8b5d1498acf4dc9
2020-04-14appveyor: Remove clcacheMarcoFalke
2020-04-14appveyor: Disable functional tests for nowMarcoFalke
Also add a draft for a Windows build on cirrus. The draft can be finished later.
2020-04-08appveyor: Enable minimal unit test logging to aid debuggingMarcoFalke
2020-01-25Updated appveyor job to checkout a specific vcpkg commit ID.Aaron Clauson
2019-12-12Update msvc build for Visual Studio 2019 v16.4Aaron Clauson
msvc warning C4834 for the Bitcoin Core build was introduced by Visual Studio 16.4.0. This PR adds an ignore rule for the warning (it's related to the nodiscard attribute and is not considered relevant). An additional side effect of the msvc compiler update is the prebuilt Qt5.9.8 libraries cannot be linked due to being built with an earlier version of the compiler. To fix this a new Qt5.9.8 version has been compiled and the appveyor job updated to use them. The GitHub Actions job needs to continue to use the original Qt5.9.8 libraries until the latest GitHub Windows image also updates to >= Visual Studio 2019 v16.4.
2019-11-10Moves vcpkg list to a text file and updates the appveyor job and readme to ↵Aaron Clauson
use it.
2019-11-06Updated appveyor config:Aaron Clauson
- Update build image from Visual Studio 2017 to Visual Studio 2019. - Updated Qt static library from Qt5.9.7 to Qt5.9.8. - Added commands to update vcpkg port files (this does not update already installed packages). - Updated vcpkg package list as per #17309. - Removed commands setting common project file options. Now done via common.init.vcxproj include. - Changed msbuild verbosity from normal to quiet. Normal rights a LOT of logs and impacts appveyor job duration. Updated msvc project configs: - Updated platform toolset from v141 to v142. - Updated Qt static library from Qt5.9.7 to Qt5.9.8. - Added ignore for linker warning building bitcoin-qt program. - Added missing util/str.cpp class file to test_bitcoin project file.
2019-09-08Added libbitcoin_qt and bitcoin-qt to the msbuild configuration.Aaron Clauson
2019-07-31Changes the verbosity of msbuild from quiet to normal in the appveyor ↵Aaron Clauson
script. Increasing the verbosity helps to identify the cause of build errors which is the main purpose of the appveyor script.
2019-07-01[MSVC] Copy build output to src/ automatically after buildnicolas.dorier
2019-06-21[MSVC]: Create the config.ini as part of bitcoind buildnicolas.dorier
2019-04-26appveyor: Write @PACKAGE_NAME@ to configMarcoFalke
2019-03-01appveyor: Don't build debug libraries instead of "build and delete"Chun Kuan Lee
2019-02-17appveyor: Remove unused NDEBUG removalChun Kuan Lee
2019-02-17Merge #15398: msvc: add rapidcheck property testsWladimir J. van der Laan
d067e81dcf574b6504813bbf742cd5af057e8e9b msvc: add rapid check property tests (Chun Kuan Lee) Pull request description: This PR add the property tests into the binaries built by MSVC. And another trivial change is that I reordered the appveyor package list. Tree-SHA512: 25d66db464beb7b512cc1f88d8557d6a047000a97d78f49884bb91a65ec142e0458039c919f51bf73413359fcf3e63e1ea4d76586b862f1c140d2ca05ee8b23d
2019-02-14[build] AppVeyor: clean cache when build configuration changesSjors Provoost
2019-02-12appveyor: Remove outdated librariesChun Kuan Lee
2019-02-07test_runner: Remove unused --force optionMarcoFalke
2019-02-04msvc: add rapid check property testsChun Kuan Lee
2019-02-01msvc: build leveldb locallyChun Kuan Lee
2019-02-01msvc: build secp256k1 locallyChun Kuan Lee
2019-01-15Fix remaining compiler warnings (MSVC). Move disabling of specific warnings ↵practicalswift
from /nowarn to project file.
2018-11-06appveyor: Script improvement part IIChun Kuan Lee
2018-11-01test_runner: Remove travis specific codeMarcoFalke
2018-10-24appveyor: Enable multiwallet testChun Kuan Lee
2018-10-05appveyor: trivial build cache modificationsChun Kuan Lee
2018-10-03tests: Make appveyor run with --useclipracticalswift
2018-09-26tests: exclude all tests with difference parametersChun Kuan Lee
2018-09-25Merge #14306: AppVeyor: Move AppVeyor YAML to dot-file-style YAMLMarcoFalke
ff40357da1 AppVeyor: Move AppVeyor YAML to dot-file-style YAML (Mitchell Cash) Pull request description: AppVeyor supports dot-file-style YAML named `.appveyor.yml` as is. This helps keep the root of the repository clean(ish) and readable by having the CI files as dot-files. Source: https://www.appveyor.com/docs/build-configuration/#yaml-file-alternative-naming Tree-SHA512: da2a78aff775e5e146f0784b1a6617d0371a5821da8a53be9e4aa57409cb16360f43d0afa5745f81f776599950cab4219a5d7ee7247d42e25861963ea487db66
2018-09-25AppVeyor: Move AppVeyor YAML to dot-file-style YAMLMitchell Cash
AppVeyor supports dot-file-style YAML named .appveyor.yml as is. This helps keep the root of the repository clean(ish) and readable by having the CI files as dot-files.
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-01 11:13:56 +0000