gamzinav/haproxy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
haproxy/.github/matrix.py

212 lines
5.9 KiB
Python
Raw Normal View History

CI: Make matrix.py executable and add shebang It's a script, allow executing this as a script without needing to invoke `python3` manually.
2021-06-08 15:14:35 +02:00
#!/usr/bin/python3
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
# Copyright 2019 Ilya Shipitsin <chipitsine@gmail.com>
# Copyright 2020 Tim Duesterhus <tim@bastelstu.be>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version
# 2 of the License, or (at your option) any later version.
import json
CI: Pass the github.event_name to matrix.py This is a preparation to later run some matrix entries on schedule only. Within the matrix.py script it can now be detected whether the workflow is running on schedule by using: if build_type == "schedule": matrix.append(...)
2020-11-20 00:16:00 +01:00
import sys
CI: determine actual LibreSSL version dynamically this change introduce "LIBRESSL_VERSION=latest" semantic, which scans http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ and detects latest release. LIBRESSL_VERSION=2.9.2 is removed from the matrix.
2022-05-13 21:59:38 +05:00
import urllib.request
import re
CI: Pass the github.event_name to matrix.py This is a preparation to later run some matrix entries on schedule only. Within the matrix.py script it can now be detected whether the workflow is running on schedule by using: if build_type == "schedule": matrix.append(...)
2020-11-20 00:16:00 +01:00
if len(sys.argv) == 2:
build_type = sys.argv[1]
else:
print("Usage: {} <build_type>".format(sys.argv[0]), file=sys.stderr)
sys.exit(1)
print("Generating matrix for type '{}'.".format(build_type))
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
def clean_os(os):
if os == "ubuntu-latest":
return "Ubuntu"
elif os == "macos-latest":
return "macOS"
return os.replace("-latest", "")
def clean_ssl(ssl):
return ssl.replace("_VERSION", "").lower()
CI: determine actual OpenSSL version dynamically this change introduce "OPENSSL_VERSION=latest" semantic, which scans https://api.github.com/repos/openssl/openssl/tags and detects latest release.
2022-05-20 23:02:38 +05:00
def determine_latest_openssl(ssl):
openssl_tags = urllib.request.urlopen("https://api.github.com/repos/openssl/openssl/tags")
tags = json.loads(openssl_tags.read().decode('utf-8'))
latest_tag = ''
for tag in tags:
name = tag['name']
if "openssl-" in name:
if name > latest_tag:
latest_tag = name
return "OPENSSL={}".format(latest_tag[8:])
CI: determine actual LibreSSL version dynamically this change introduce "LIBRESSL_VERSION=latest" semantic, which scans http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ and detects latest release. LIBRESSL_VERSION=2.9.2 is removed from the matrix.
2022-05-13 21:59:38 +05:00
def determine_latest_libressl(ssl):
libressl_download_list = urllib.request.urlopen("http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/")
for line in libressl_download_list.readlines():
decoded_line = line.decode("utf-8")
if "libressl-" in decoded_line and ".tar.gz.asc" in decoded_line:
l = re.split("libressl-|.tar.gz.asc", decoded_line)[1]
return "LIBRESSL={}".format(l)
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
def clean_compression(compression):
return compression.replace("USE_", "").lower()
def get_asan_flags(cc):
CI: re-enable gcc asan builds for some unclear reasons asan builds were limited to clang only. let us enable them for gcc as well
2022-07-02 10:30:28 +05:00
return [
"USE_OBSOLETE_LINKER=1",
'DEBUG_CFLAGS="-g -fsanitize=address"',
'LDFLAGS="-fsanitize=address"',
'CPU_CFLAGS.generic="-O1"',
]
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
matrix = []
# Ubuntu
os = "ubuntu-latest"
TARGET = "linux-glibc"
for CC in ["gcc", "clang"]:
matrix.append(
{
"name": "{}, {}, no features".format(clean_os(os), CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [],
}
)
matrix.append(
{
"name": "{}, {}, all features".format(clean_os(os), CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [
"USE_ZLIB=1",
CI: Github Actions: re-enable Opentracing Miroslav already fixed the build of OpenTracing so we can re-enable it in the CI. For now variables are disabled but this will change soon.
2021-09-12 07:01:36 +02:00
"USE_OT=1",
CI: github actions: use cache for OpenTracing this caches OpenTracing libs between builds, should save couple of minutes for each build.
2022-01-13 11:36:28 +05:00
"OT_INC=${HOME}/opt-ot/include",
"OT_LIB=${HOME}/opt-ot/lib",
CI: github actions: add OpenTracing builds let us add OpenTracing module to "all features" builds
2021-05-18 09:46:43 +00:00
"OT_RUNPATH=1",
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
"USE_PCRE=1",
"USE_PCRE_JIT=1",
"USE_LUA=1",
"USE_OPENSSL=1",
"USE_SYSTEMD=1",
"USE_WURFL=1",
CONTRIB: move src/wurfl.c and contrib/wurfl to addons/wurfl Both the source file and the dummy library are now at the same place. Maybe the build howto could be moved there as well to make things even cleaner. The Makefile, MAINTAINERS, doc, and vtest matrix were updated.
2021-04-02 16:39:44 +02:00
"WURFL_INC=addons/wurfl/dummy",
"WURFL_LIB=addons/wurfl/dummy",
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
"USE_DEVICEATLAS=1",
CONTRIB: move src/da.c and contrib/deviceatlas to addons/deviceatlas Both the source file and the dummy library are now at the same place. Maybe the build howto could be moved there as well to make things even cleaner. The Makefile, MAINTAINERS, doc, github build matrix, coverity checks and travis CI's build were updated.
2021-04-02 16:19:39 +02:00
"DEVICEATLAS_SRC=addons/deviceatlas/dummy",
CONTRIB: move prometheus-exporter to addons/promex Let's start to better organize the addons by moving promex there (and with an easier directory name). The makefile and maintainers files were updated, as well as the CI's build matrix.
2021-04-02 15:35:19 +02:00
"USE_PROMEX=1",
CI: github actions: enable 51degrees feature
2020-11-26 20:59:42 +05:00
"USE_51DEGREES=1",
CONTRIB: move 51Degrees to addons/51degrees Now it's much cleaner, both 51d.c and the dummy library live together and are easier to spot and maintain. The build howto probably ought to be moved there as well. Makefile, docs and MAINTAINERS were updated, as well as the github CI's build matrix, travis CI's, and coverity checks.
2021-04-02 16:12:32 +02:00
"51DEGREES_SRC=addons/51degrees/dummy/pattern",
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
],
}
)
CI: Remove obsolete USE_SLZ=1 CI job Using SLZ is a default, thus this build is equivalent to the "no features" build.
2021-08-14 14:36:55 +02:00
for compression in ["USE_ZLIB=1"]:
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
matrix.append(
{
"name": "{}, {}, gz={}".format(
clean_os(os), CC, clean_compression(compression)
),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [compression],
}
)
for ssl in [
"stock",
"OPENSSL_VERSION=1.0.2u",
CI: determine actual OpenSSL version dynamically this change introduce "OPENSSL_VERSION=latest" semantic, which scans https://api.github.com/repos/openssl/openssl/tags and detects latest release.
2022-05-20 23:02:38 +05:00
"OPENSSL_VERSION=latest",
CI: determine actual LibreSSL version dynamically this change introduce "LIBRESSL_VERSION=latest" semantic, which scans http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ and detects latest release. LIBRESSL_VERSION=2.9.2 is removed from the matrix.
2022-05-13 21:59:38 +05:00
"LIBRESSL_VERSION=latest",
BUILD: SSL: add QUICTLS to build matrix It also enables QUIC when QUICTLS is used.
2021-11-18 18:27:57 +05:00
"QUICTLS=yes",
CI: Github Actions: temporarily disable BoringSSL builds A recent update to BoringSSL broke the build again, and given that it's not used except for QUIC development, let's temporarily disable it until the issue is analysed and fixed.
2021-09-02 17:32:43 +02:00
# "BORINGSSL=yes",
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
]:
flags = ["USE_OPENSSL=1"]
BUILD: SSL: add QUICTLS to build matrix It also enables QUIC when QUICTLS is used.
2021-11-18 18:27:57 +05:00
if ssl == "BORINGSSL=yes" or ssl == "QUICTLS=yes":
CI: Github Actions: enable USE_QUIC=1 for BoringSSL builds if haproxy is built against BoringSSL, let us add USE_QUIC=1 dynamically
2021-05-09 21:27:28 +05:00
flags.append("USE_QUIC=1")
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
if ssl != "stock":
flags.append("SSL_LIB=${HOME}/opt/lib")
flags.append("SSL_INC=${HOME}/opt/include")
CI: determine actual LibreSSL version dynamically this change introduce "LIBRESSL_VERSION=latest" semantic, which scans http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ and detects latest release. LIBRESSL_VERSION=2.9.2 is removed from the matrix.
2022-05-13 21:59:38 +05:00
if "LIBRESSL" in ssl and "latest" in ssl:
ssl = determine_latest_libressl(ssl)
CI: determine actual OpenSSL version dynamically this change introduce "OPENSSL_VERSION=latest" semantic, which scans https://api.github.com/repos/openssl/openssl/tags and detects latest release.
2022-05-20 23:02:38 +05:00
if "OPENSSL" in ssl and "latest" in ssl:
ssl = determine_latest_openssl(ssl)
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
matrix.append(
{
"name": "{}, {}, ssl={}".format(clean_os(os), CC, clean_ssl(ssl)),
"os": os,
"TARGET": TARGET,
"CC": CC,
"ssl": ssl,
"FLAGS": flags,
}
)
# ASAN
os = "ubuntu-latest"
TARGET = "linux-glibc"
CI: re-enable gcc asan builds for some unclear reasons asan builds were limited to clang only. let us enable them for gcc as well
2022-07-02 10:30:28 +05:00
for CC in ["gcc","clang"]:
matrix.append(
{
"name": "{}, {}, ASAN, all features".format(clean_os(os), CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": get_asan_flags(CC)
+ [
"USE_ZLIB=1",
"USE_OT=1",
"OT_INC=${HOME}/opt-ot/include",
"OT_LIB=${HOME}/opt-ot/lib",
"OT_RUNPATH=1",
"USE_PCRE=1",
"USE_PCRE_JIT=1",
"USE_LUA=1",
"USE_OPENSSL=1",
"USE_SYSTEMD=1",
"USE_WURFL=1",
"WURFL_INC=addons/wurfl/dummy",
"WURFL_LIB=addons/wurfl/dummy",
"USE_DEVICEATLAS=1",
"DEVICEATLAS_SRC=addons/deviceatlas/dummy",
"USE_PROMEX=1",
"USE_51DEGREES=1",
"51DEGREES_SRC=addons/51degrees/dummy/pattern",
],
}
)
CI: Expand use of GitHub Actions for CI Travis is becoming overall increasingly unreliable lately. We've already seen that the timing sensitive tests regularly fail and thus they were disabled. Additionally they recently announced a new pricing model that caps the number of minutes for Open Source projects: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing GitHub Actions VMs are working well, possibly allowing to use custom runners for special tasks in the future. In addition to this better performance its workflow configuration language is more expressive compared to the Travis CI one. Specifically the build matrix does not need to be specified in YAML. Instead it can be generated ad-hoc using a script. This allows us to cleanly define the various build configurations without having an unreadable 80 line mess where the flags are inconsistently activated. As an example in the current Travis CI configuration the prometheus exporter is tested together with LibreSSL 2.9.2 for whatever reason. In addition to all the previous points the UI of Travis is not that nice. On GitHub you are just seeing that "Travis failed" without any details which exact job failed. This requires you to visit the slow Travis page and look up the details there. GitHub Actions creates a single entry for each configuration that is tested, allowing you to see the details without needing to leave GitHub. This new GitHub Actions workflow aims to reproduce the configurations tested in Travis. It comes close, but is not completely there, yet. Consider this patch a proof of concept that will evolve in the future, ideally with Ilya's expertise. The current configurations are as follows. Each one is tested with both gcc and clang. - All features disabled (no USE flags) - All features enabled (all USE flags) - Standalone test of each of the supported compression libraries: - USE_ZLIB=1 - USE_SLZ=1 - Standalone test of various SSL libraries: - stock (the SSL installed by default on the VM) - OpenSSL 1.0.2u - LibreSSL 2.9.2, 3.0.2, 3.1.1 - All features enabled with ASAN (clang only) Future additions of new tests should take care to not test unrelated stuff. Instead a distinct configuration should be added. Additionally there is a Mac OS test with clang and all features disabled. Known issues: - Apparently the git commit is not properly detected during build. The HEAD currently shows as 2.4-dev0.
2020-07-28 23:00:35 +02:00
# macOS
os = "macos-latest"
TARGET = "osx"
for CC in ["clang"]:
matrix.append(
{
"name": "{}, {}, no features".format(clean_os(os), CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [],
}
)
# Print matrix
print(json.dumps(matrix, indent=4, sort_keys=True))
print("::set-output name=matrix::{}".format(json.dumps({"include": matrix})))
Reference in New Issue Copy Permalink