phantom/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-01-14 13:52:36 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions
bitcoin/ci/test/00_setup_env_i686_centos.sh

19 lines
807 B
Bash
Raw Normal View History

ci: Combine 32-bit build with CentOS 7 build
2020-01-08 19:36:46 -03:00
#!/usr/bin/env bash
#
scripted-diff: Bump copyright headers -BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py update ./ -END VERIFY SCRIPT- Commits of previous years: - 2021: f47dda2c58b5d8d623e0e7ff4e74bc352dfa83d7 - 2020: fa0074e2d82928016a43ca408717154a1c70a4db - 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
2022-12-24 20:49:50 -03:00
# Copyright (c) 2020-2022 The Bitcoin Core developers
ci: Combine 32-bit build with CentOS 7 build
2020-01-08 19:36:46 -03:00
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
export LC_ALL=C.UTF-8
export HOST=i686-pc-linux-gnu
ci: Bump CentOS 8 image
2022-01-31 07:19:23 -03:00
export CONTAINER_NAME=ci_i686_centos
scripted-diff: ci: Rework docker naming DOCKER in names is confusingly used as synonym for "image", "container", and "ci". Fix the confusion by picking the term that fits the context. -BEGIN VERIFY SCRIPT- ren() { sed -i "s:$1:$2:g" $( git grep -l "$1" ) ; } ren DOCKER_PACKAGES CI_BASE_PACKAGES # This better reflects that they are the common base for all CI # containers. ren DOCKER_ID CI_CONTAINER_ID # This is according to the documentation of "--detach , -d: Run # container in background and print container ID". ren DOCKER_NAME_TAG CI_IMAGE_NAME_TAG # This avoids confusing with CONTAINER_NAME and clarifies that it is an # image. ren DOCKER_ADMIN CI_CONTAINER_CAP # This clarifies that it is a capability added to the container. ren DOCKER_CI_CMD_PREFIX CI_EXEC_CMD_PREFIX # This brings it in line with the CI_EXEC naming. -END VERIFY SCRIPT-
2023-01-09 06:22:18 -03:00
export CI_IMAGE_NAME_TAG=quay.io/centos/centos:stream8
Bump minimum python version to 3.7
2023-01-17 17:55:37 -03:00
export CI_BASE_PACKAGES="gcc-c++ glibc-devel.x86_64 libstdc++-devel.x86_64 glibc-devel.i686 libstdc++-devel.i686 ccache libtool make git python38 python38-pip which patch lbzip2 xz procps-ng dash rsync coreutils bison"
ci: Allow PIP_PACKAGES on centos This was added in 7fc5e865b93af59364e9c8bf75ec68b4decc7e5d but I can't see a reason why this should be forbidden.
2022-10-03 07:57:50 -03:00
export PIP_PACKAGES="pyzmq"
ci: Combine 32-bit build with CentOS 7 build
2020-01-08 19:36:46 -03:00
export GOAL="install"
ci: avoid using -Werror for older compilers Don't enable `-Werror` (in the CI) for compilers at least older than our current release compiler (GCC 10). It provides little-to-no value, other than turning compiler bugs & false positives into build failures, and we aren't going to mutate perfectly fine/working code, for the sake of avoid a warning that shouldn't even exist. I also do not see the point of playing whack-a-mole and turning off various warnings/trying to further work around the broken compiler, just to acheive warningless builds for the sake of warningless builds. One anecdote from "How SQLite Is Tested": > Static analysis has found a few bugs in SQLite, but those are the > exceptions. More bugs have been introduced into SQLite while trying > to get it to compile without warnings than have been found by static > analysis. https://www.sqlite.org/testing.html.
2023-02-01 08:11:40 -03:00
export NO_WERROR=1 # GCC 8
build: enable external signer by default
2020-06-16 12:56:11 -04:00
export BITCOIN_CONFIG="--enable-zmq --with-gui=qt5 --enable-reduce-exports"
ci: Combine 32-bit build with CentOS 7 build
2020-01-08 19:36:46 -03:00
export CONFIG_SHELL="/bin/dash"
ci: Run i686 centos ci config on cirrus
2020-07-25 08:37:16 -04:00
export TEST_RUNNER_ENV="LC_ALL=en_US.UTF-8"
Reference in a new issue Copy permalink