RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/.github/matrix.py

261 lines
7.4 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 13:14:35 +00: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 21:00:35 +00: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.
CI: Add in-memory cache for the latest OpenSSL/LibreSSL These functions were previously called once per compiler. Add the `lru_cache` decorator to only perform one HTTP request each.
2022-12-29 16:40:25 +00:00
import functools
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 21:00:35 +00:00
import json
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
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-19 23:16:00 +00: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 16:59:38 +00:00
import urllib.request
CI: Replace the deprecated `::set-output` command by writing to $GITHUB_OUTPUT in matrix.py As announced in https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ the `::set-output` command is deprecated, because processes during the workflow execution might output untrusted information that might include the `::set-output` command, thus allowing these untrusted information to hijack the build. The replacement is writing to the file indicated by the `$GITHUB_OUTPUT` environment variable.
2022-10-14 17:46:06 +00:00
from os import environ
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-19 23:16:00 +00:00
if len(sys.argv) == 2:
CI: github: split ssl lib selection based on git branch when *SSL_VERSION="latest" behaviour was introduced, it seems to be fine for development branches, but too intrusive for stable branches. let us limit "latest" semantic only for development builds, if branch name contains "haproxy-" it is supposed to be stable branch, no latest openssl should be taken [wla: must be backported as far as 2.6] Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-12-12 14:15:22 +00:00
ref_name = sys.argv[1]
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-19 23:16:00 +00:00
else:
CI: github: split ssl lib selection based on git branch when *SSL_VERSION="latest" behaviour was introduced, it seems to be fine for development branches, but too intrusive for stable branches. let us limit "latest" semantic only for development builds, if branch name contains "haproxy-" it is supposed to be stable branch, no latest openssl should be taken [wla: must be backported as far as 2.6] Signed-off-by: William Lallemand <wlallemand@haproxy.org>
2022-12-12 14:15:22 +00:00
print("Usage: {} <ref_name>".format(sys.argv[0]), file=sys.stderr)
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-19 23:16:00 +00:00
sys.exit(1)
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
#
# this CI is used for both development and stable branches of HAProxy
#
# naming convention used, if branch name matches:
#
# "haproxy-" - stable branches
# otherwise - development branch (i.e. "latest" ssl variants, "latest" github images)
#
CI: Improve headline in matrix.py Since 4a04cd35ae89bf6a3bb7620f7a49804de3240ac4 (CI: github: split ssl lib selection based on git branch) the branch, instead of the workflow type is passed. The headline should reflect that.
2022-12-29 16:40:24 +00:00
print("Generating matrix for branch '{}'.".format(ref_name))
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 21:00:35 +00:00
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
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 21:00:35 +00:00
def clean_ssl(ssl):
return ssl.replace("_VERSION", "").lower()
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
def get_all_github_tags(url):
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
headers = {}
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
if environ.get("GITHUB_TOKEN") is not None:
headers["Authorization"] = "token {}".format(environ.get("GITHUB_TOKEN"))
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
request = urllib.request.Request(url, headers=headers)
CI: more granular failure on generating build matrix when some api endpoints used for determine latest OpenSSL, LibreSSL are unavailable, fail only those builds, not entire matrix
2023-04-26 18:39:39 +00:00
try:
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
tags = urllib.request.urlopen(request)
CI: more granular failure on generating build matrix when some api endpoints used for determine latest OpenSSL, LibreSSL are unavailable, fail only those builds, not entire matrix
2023-04-26 18:39:39 +00:00
except:
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
return None
tags = json.loads(tags.read().decode("utf-8"))
return [tag['name'] for tag in tags]
@functools.lru_cache(5)
def determine_latest_openssl(ssl):
tags = get_all_github_tags("https://api.github.com/repos/openssl/openssl/tags")
if not tags:
return "OPENSSL_VERSION=failed_to_detect"
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
latest_tag = ""
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 18:02:38 +00:00
for tag in tags:
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
if "openssl-" in tag:
if tag > latest_tag:
latest_tag = tag
CI: SSL: use proper version generating when "latest" semantic is used both "OPENSSL_VERSION=latest" and "LIBRESSL_VERSION=latest" processing introduced errors when build-ssl.sh script was invoked. that error in turn led to skipping custom openssl build and haproxy was linked against stock openssl, i.e. openssl-1.1.1
2022-10-11 07:10:57 +00:00
return "OPENSSL_VERSION={}".format(latest_tag[8:])
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 18:02:38 +00:00
CI: add support to matrix.py to determine the latest AWS-LC release Refactor the existing OpenSSL tag parsing logic to share some of GitHub tag logic. OpenSSL and AWS-LC don't follow the same naming convention so each library has it's own sorting logic.
2023-09-05 23:27:28 +00:00
def aws_lc_version_string_to_num(version_string):
return tuple(map(int, version_string[1:].split('.')))
def aws_lc_version_valid(version_string):
return re.match('^v[0-9]+(\.[0-9]+)*$', version_string)
@functools.lru_cache(5)
def determine_latest_aws_lc(ssl):
tags = get_all_github_tags("https://api.github.com/repos/aws/aws-lc/tags")
if not tags:
return "AWS_LC_VERSION=failed_to_detect"
valid_tags = list(filter(aws_lc_version_valid, tags))
latest_tag = max(valid_tags, key=aws_lc_version_string_to_num)
return "AWS_LC_VERSION={}".format(latest_tag[1:])
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
CI: Add in-memory cache for the latest OpenSSL/LibreSSL These functions were previously called once per compiler. Add the `lru_cache` decorator to only perform one HTTP request each.
2022-12-29 16:40:25 +00:00
@functools.lru_cache(5)
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 16:59:38 +00:00
def determine_latest_libressl(ssl):
CI: more granular failure on generating build matrix when some api endpoints used for determine latest OpenSSL, LibreSSL are unavailable, fail only those builds, not entire matrix
2023-04-26 18:39:39 +00:00
try:
libressl_download_list = urllib.request.urlopen(
"https://cdn.openbsd.org/pub/OpenBSD/LibreSSL/"
)
except:
return "LIBRESSL_VERSION=failed_to_detect"
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 16:59:38 +00:00
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:
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
l = re.split("libressl-|.tar.gz.asc", decoded_line)[1]
CI: SSL: use proper version generating when "latest" semantic is used both "OPENSSL_VERSION=latest" and "LIBRESSL_VERSION=latest" processing introduced errors when build-ssl.sh script was invoked. that error in turn led to skipping custom openssl build and haproxy was linked against stock openssl, i.e. openssl-1.1.1
2022-10-11 07:10:57 +00:00
return "LIBRESSL_VERSION={}".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 21:00:35 +00:00
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
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 21:00:35 +00: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 05:30:28 +00: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 21:00:35 +00:00
matrix = []
# Ubuntu
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
if "haproxy-" in ref_name:
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
os = "ubuntu-22.04" # stable branch
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
else:
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
os = "ubuntu-latest" # development branch
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
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 21:00:35 +00:00
TARGET = "linux-glibc"
for CC in ["gcc", "clang"]:
matrix.append(
{
CI: github: split matrix for development and stable branches ML ref: https://www.mail-archive.com/haproxy@formilux.org/msg42934.html we agreed to use "latest" images for development branches and fixed images for stable branches Can be backported to 2.6.
2022-12-14 13:23:24 +00:00
"name": "{}, {}, no features".format(os, CC),
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 21:00:35 +00:00
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [],
}
)
matrix.append(
{
CI: github: split matrix for development and stable branches ML ref: https://www.mail-archive.com/haproxy@formilux.org/msg42934.html we agreed to use "latest" images for development branches and fixed images for stable branches Can be backported to 2.6.
2022-12-14 13:23:24 +00:00
"name": "{}, {}, all features".format(os, CC),
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 21:00:35 +00:00
"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 05:01:36 +00: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 06:36:28 +00: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 21:00:35 +00: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 14:39:44 +00: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 21:00:35 +00: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 14:19:39 +00: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 13:35:19 +00:00
"USE_PROMEX=1",
CI: github actions: enable 51degrees feature
2020-11-26 15:59:42 +00: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 14:12:32 +00: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 21:00:35 +00:00
],
}
)
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
# ASAN
CI: github: remove redundant ASAN loop it was there because we only ran ASAN for clang, now no need to separate loop Can be backported to 2.6.
2022-12-14 13:18:20 +00:00
matrix.append(
{
CI: github: split matrix for development and stable branches ML ref: https://www.mail-archive.com/haproxy@formilux.org/msg42934.html we agreed to use "latest" images for development branches and fixed images for stable branches Can be backported to 2.6.
2022-12-14 13:23:24 +00:00
"name": "{}, {}, ASAN, all features".format(os, CC),
CI: github: remove redundant ASAN loop it was there because we only ran ASAN for clang, now no need to separate loop Can be backported to 2.6.
2022-12-14 13:18:20 +00:00
"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: 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 12:36:55 +00: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 21:00:35 +00:00
matrix.append(
{
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
"name": "{}, {}, gz={}".format(os, CC, clean_compression(compression)),
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 21:00:35 +00:00
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [compression],
}
)
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
ssl_versions = [
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 21:00:35 +00:00
"stock",
"OPENSSL_VERSION=1.0.2u",
CI: github: reintroduce openssl 1.1.1 OpenSSL 1.1.1 is not tested anymore since github updated "ubuntu-latest" to 22.04, let's reintroduce this version.
2022-12-12 07:52:03 +00:00
"OPENSSL_VERSION=1.1.1s",
BUILD: SSL: add QUICTLS to build matrix It also enables QUIC when QUICTLS is used.
2021-11-18 13:27:57 +00:00
"QUICTLS=yes",
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
# "BORINGSSL=yes",
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
]
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
if "haproxy-" not in ref_name: # development branch
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
ssl_versions = ssl_versions + [
"OPENSSL_VERSION=latest",
"LIBRESSL_VERSION=latest",
]
for ssl in ssl_versions:
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 21:00:35 +00:00
flags = ["USE_OPENSSL=1"]
CI: enable QUIC for LibreSSL builds since LibreSSL-3.6.x supports QUIC, let us enable it
2022-11-02 06:59:37 +00:00
if ssl == "BORINGSSL=yes" or ssl == "QUICTLS=yes" or "LIBRESSL" in ssl:
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 16:27:28 +00: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 21:00:35 +00: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 16:59:38 +00: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 18:02:38 +00: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 21:00:35 +00:00
matrix.append(
{
CI: github: split matrix for development and stable branches ML ref: https://www.mail-archive.com/haproxy@formilux.org/msg42934.html we agreed to use "latest" images for development branches and fixed images for stable branches Can be backported to 2.6.
2022-12-14 13:23:24 +00:00
"name": "{}, {}, ssl={}".format(os, CC, clean_ssl(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 21:00:35 +00:00
"os": os,
"TARGET": TARGET,
"CC": CC,
"ssl": ssl,
"FLAGS": flags,
}
)
# macOS
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
if "haproxy-" in ref_name:
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
os = "macos-12" # stable branch
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
else:
CI: add naming convention documentation branches "haproxy-" stand for stable branches, otherwise development
2023-07-14 22:00:48 +00:00
os = "macos-latest" # development branch
CI: Use proper `if` blocks instead of conditional expressions in matrix.py For complex expressions, such as the ones modified, the condition expression is much less readable, especially with the actual condition in the middle of the "then" and "else" part.
2022-12-29 16:40:26 +00:00
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 21:00:35 +00:00
TARGET = "osx"
for CC in ["clang"]:
matrix.append(
{
CI: github: split matrix for development and stable branches ML ref: https://www.mail-archive.com/haproxy@formilux.org/msg42934.html we agreed to use "latest" images for development branches and fixed images for stable branches Can be backported to 2.6.
2022-12-14 13:23:24 +00:00
"name": "{}, {}, no features".format(os, CC),
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 21:00:35 +00:00
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [],
}
)
# Print matrix
print(json.dumps(matrix, indent=4, sort_keys=True))
CI: Reformat `matrix.py` using `black` The initial version of matrix.py was formatted using `black` [1], but with all the later changes, the formatting diverged quite a bit. This patch reformats the script using black, fixing the indentation of some statements and shortening overlong lines. [1] https://github.com/psf/black
2022-12-29 16:40:29 +00:00
if environ.get("GITHUB_OUTPUT") is not None:
with open(environ.get("GITHUB_OUTPUT"), "a") as f:
CI: Replace the deprecated `::set-output` command by writing to $GITHUB_OUTPUT in matrix.py As announced in https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ the `::set-output` command is deprecated, because processes during the workflow execution might output untrusted information that might include the `::set-output` command, thus allowing these untrusted information to hijack the build. The replacement is writing to the file indicated by the `$GITHUB_OUTPUT` environment variable.
2022-10-14 17:46:06 +00:00
print("matrix={}".format(json.dumps({"include": matrix})), file=f)