RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-22 04:10:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
0b7a5a64eb
haproxy/.github/matrix.py

265 lines
8.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: use semantic version compare for determing "latest" OpenSSL currently "openssl-3.2.0-beta1" wins over "openssl-3.2.0" due to string comparision. let's switch to semantic version compare
2023-12-29 22:31:39 +00:00
from packaging import version
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
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: 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:
CI: use semantic version compare for determing "latest" OpenSSL currently "openssl-3.2.0-beta1" wins over "openssl-3.2.0" due to string comparision. let's switch to semantic version compare
2023-12-29 22:31:39 +00:00
if (not latest_tag) or (version.parse(tag[8:]) > version.parse(latest_tag[8:])):
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
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()
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
def main(ref_name):
print("Generating matrix for branch '{}'.".format(ref_name))
matrix = []
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
# Ubuntu
if "haproxy-" in ref_name:
os = "ubuntu-22.04" # stable branch
else:
os = "ubuntu-latest" # development branch
TARGET = "linux-glibc"
for CC in ["gcc", "clang"]:
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +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,
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"FLAGS": [],
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
matrix.append(
{
"name": "{}, {}, all features".format(os, CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [
BUILD: makefile: also drop DEBUG_CFLAGS This one is often used as a gateway to inject regular CFLAGS, even though not designed for this. It's now ignored, but any attempt at setting it reports a warning suggesting to use CFLAGS or ARCH_FLAGS instead.
2024-04-10 16:21:18 +00:00
'DEBUG="-DDEBUG_LIST"',
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"USE_ZLIB=1",
"USE_OT=1",
"OT_INC=${HOME}/opt-ot/include",
"OT_LIB=${HOME}/opt-ot/lib",
"OT_RUNPATH=1",
CI: use USE_PCRE2 instead of USE_PCRE USE_PCRE2 is recommended, I guess USE_PCRE is left unintentionally
2024-05-29 19:59:16 +00:00
"USE_PCRE2=1",
"USE_PCRE2_JIT=1",
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"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: 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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
# ASAN
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: 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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"name": "{}, {}, ASAN, 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,
CI: github: abandon asan matrix.py helper that helper was useful in days when we beleived that gcc and clang require different flags. those days are gone.
2024-02-02 19:33:15 +00:00
"FLAGS": [
"USE_OBSOLETE_LINKER=1",
BUILD: makefile: drop the ARCH variable and better document ARCH_FLAGS ARCH_FLAGS was always present and is documented as being fed to both CC and LD during the build. This is meant for options that need to be consistent between the two stages such as -pg, -flto, -fsanitize=address, -m64, -g etc. Its doc was lacking a bit of clarity though, and it was not enumerated in the makefile's variables list. ARCH however was only documented as affecting ARCH_FLAGS, and was just never used as the only two really usable and supported ARCH_FLAGS options were -m32 and -m64. In addition it was even written in the makefile that it was CPU that was affecting the ARCH_FLAGS. Let's just drop ARCH and improve the documentation on ARCH_FLAGS. Again, if ARCH is set, a warning is emitted explaining how to proceed. ARCH_FLAGS is now preset to -g so that we finally have a correct place to deal with such debugging options that need to be passed to both stages. The fedora and musl CI workflows were updated to also use it instead of sticking to duplicate DEBUG_CFLAGS+LDFLAGS. It's also worth noting that BUILD_ARCH was being passed to the build process and never used anywhere in the code, so its removal will not be noticed.
2024-04-10 15:58:00 +00:00
'ARCH_FLAGS="-g -fsanitize=address"',
BUILD: makefile: move -O2 from CPU_CFLAGS to OPT_CFLAGS CPU_CFLAGS is meant to set the CPU-specific options (-mcpu, -march etc). The fact that it also includes the optimization level is annoying because one cannot be set without replacing the other. Let's move the optimization level to a new independent OPT_CFLAGS that is added early to the list, so that other CFLAGS (including CPU_CFLAGS) can continue to override it if necessary.
2024-04-10 14:26:34 +00:00
'OPT_CFLAGS="-O1"',
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"USE_ZLIB=1",
"USE_OT=1",
"OT_INC=${HOME}/opt-ot/include",
"OT_LIB=${HOME}/opt-ot/lib",
"OT_RUNPATH=1",
CI: use USE_PCRE2 instead of USE_PCRE USE_PCRE2 is recommended, I guess USE_PCRE is left unintentionally
2024-05-29 19:59:16 +00:00
"USE_PCRE2=1",
"USE_PCRE2_JIT=1",
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
"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 21:00:35 +00:00
}
)
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
for compression in ["USE_ZLIB=1"]:
matrix.append(
{
"name": "{}, {}, gz={}".format(os, CC, clean_compression(compression)),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [compression],
}
)
ssl_versions = [
"stock",
"OPENSSL_VERSION=1.0.2u",
"OPENSSL_VERSION=1.1.1s",
"QUICTLS=yes",
CI: github: upgrade the WolfSSL job to 5.7.0 WolfSSL 5.70 was released in March 2024, let's upgrade our CI job to this version.
2024-05-28 17:16:03 +00:00
"WOLFSSL_VERSION=5.7.0",
CI: github: add awslc 1.16.0 to the push CI Add a awslc 1.16.0 to the push CI. Since this is a fixed version it shouldn't cause problems.
2023-10-11 09:38:27 +00:00
"AWS_LC_VERSION=1.16.0",
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00: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 21:00:35 +00:00
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
if "haproxy-" not in ref_name: # development branch
ssl_versions = ssl_versions + [
"OPENSSL_VERSION=latest",
"LIBRESSL_VERSION=latest",
]
for ssl in ssl_versions:
flags = ["USE_OPENSSL=1"]
CI: github: add awslc 1.16.0 to the push CI Add a awslc 1.16.0 to the push CI. Since this is a fixed version it shouldn't cause problems.
2023-10-11 09:38:27 +00:00
if ssl == "BORINGSSL=yes" or ssl == "QUICTLS=yes" or "LIBRESSL" in ssl or "WOLFSSL" in ssl or "AWS_LC" in ssl:
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
flags.append("USE_QUIC=1")
CI: github: add a wolfssl entry to the CI Add a build with wolfssl 5.6.3 to the github CI.
2023-10-09 21:36:13 +00:00
if "WOLFSSL" in ssl:
flags.append("USE_OPENSSL_WOLFSSL=1")
CI: github: add awslc 1.16.0 to the push CI Add a awslc 1.16.0 to the push CI. Since this is a fixed version it shouldn't cause problems.
2023-10-11 09:38:27 +00:00
if "AWS_LC" in ssl:
flags.append("USE_OPENSSL_AWSLC=1")
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
if ssl != "stock":
flags.append("SSL_LIB=${HOME}/opt/lib")
flags.append("SSL_INC=${HOME}/opt/include")
if "LIBRESSL" in ssl and "latest" in ssl:
ssl = determine_latest_libressl(ssl)
if "OPENSSL" in ssl and "latest" in ssl:
ssl = determine_latest_openssl(ssl)
matrix.append(
{
"name": "{}, {}, ssl={}".format(os, CC, clean_ssl(ssl)),
"os": os,
"TARGET": TARGET,
"CC": CC,
"ssl": ssl,
"FLAGS": flags,
}
)
# macOS
if "haproxy-" in ref_name:
CI: modernize macos matrix let's stick to macos-13 for stable branches and macos-14 for development branches. since macos-14 is available for Apple Silicon, some modifications are required for VTest (should be ported to VTest later) news: https://github.blog/changelog/2024-01-30-github-actions-macos-14-sonoma-is-now-available/
2024-04-19 05:16:45 +00:00
os = "macos-13" # stable branch
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
else:
CI: modernize macos matrix let's stick to macos-13 for stable branches and macos-14 for development branches. since macos-14 is available for Apple Silicon, some modifications are required for VTest (should be ported to VTest later) news: https://github.blog/changelog/2024-01-30-github-actions-macos-14-sonoma-is-now-available/
2024-04-19 05:16:45 +00:00
os = "macos-14" # development branch
CI: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
TARGET = "osx"
for CC in ["clang"]:
matrix.append(
{
"name": "{}, {}, no features".format(os, CC),
"os": os,
"TARGET": TARGET,
"CC": CC,
"FLAGS": [],
}
)
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
# Print matrix
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
print(json.dumps(matrix, indent=4, sort_keys=True))
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
if environ.get("GITHUB_OUTPUT") is not None:
with open(environ.get("GITHUB_OUTPUT"), "a") as f:
print("matrix={}".format(json.dumps({"include": matrix})), file=f)
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: Update matrix.py so all code is contained in functions. Refactor matrix.py so all the logic is contained inside either helper functions or a new main function. Run the new main function by default. This lets other GitHub actions use functions in the python code without generating the whole matrix.
2023-09-05 23:32:50 +00:00
if __name__ == "__main__":
if len(sys.argv) == 2:
ref_name = sys.argv[1]
main(ref_name)
else:
print("Usage: {} <ref_name>".format(sys.argv[0]), file=sys.stderr)
sys.exit(1)
Reference in New Issue Copy Permalink