haproxy/.github/workflows/vtest.yml

153 lines
5.0 KiB
YAML
Raw Normal View History

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.
name: VTest
on:
push:
permissions:
contents: read
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
jobs:
# The generate-matrix job generates the build matrix using JSON output
# generated by .github/matrix.py.
generate-matrix:
name: Generate Build Matrix
runs-on: ubuntu-latest
outputs:
matrix: ${{ steps.set-matrix.outputs.matrix }}
steps:
- uses: actions/checkout@v3
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
- name: Generate Build Matrix
id: set-matrix
run: python3 .github/matrix.py "${{ github.event_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
# The Test job actually runs the tests.
Test:
name: ${{ matrix.name }}
needs: generate-matrix
runs-on: ${{ matrix.os }}
strategy:
matrix: ${{ fromJson(needs.generate-matrix.outputs.matrix) }}
fail-fast: false
env:
# Configure a short TMPDIR to prevent failures due to long unix socket
# paths.
TMPDIR: /tmp
# Force ASAN output into asan.log to make the output more readable.
ASAN_OPTIONS: log_path=asan.log
OT_CPP_VERSION: 1.6.0
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
steps:
- uses: actions/checkout@v3
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
with:
fetch-depth: 100
#
# Github Action cache key cannot contain comma, so we calculate it based on job name
#
- name: Generate cache key
id: generate-cache-key
run: |
echo "::set-output name=key::$(echo ${{ matrix.name }} | sha256sum | awk '{print $1}')"
- name: Cache SSL libs
if: ${{ matrix.ssl && matrix.ssl != 'stock' && matrix.ssl != 'BORINGSSL=yes' && matrix.ssl != 'QUICTLS=yes' }}
id: cache_ssl
uses: actions/cache@v3
with:
path: '~/opt/'
key: ssl-${{ steps.generate-cache-key.outputs.key }}
- name: Cache OpenTracing
if: ${{ contains(matrix.FLAGS, 'USE_OT=1') }}
id: cache_ot
uses: actions/cache@v3
with:
path: '~/opt-ot/'
key: ot-${{ matrix.CC }}-${{ env.OT_CPP_VERSION }}-${{ contains(matrix.name, 'ASAN') }}
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
- name: Install apt dependencies
if: ${{ startsWith(matrix.os, 'ubuntu-') }}
run: |
sudo apt-get update
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
sudo apt-get install -y \
liblua5.3-dev \
libpcre2-dev \
libsystemd-dev \
ninja-build \
socat
- name: Install brew dependencies
if: ${{ startsWith(matrix.os, 'macos-') }}
run: |
brew install socat
brew install lua
- name: Install VTest
run: |
scripts/build-vtest.sh
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
- name: Install SSL ${{ matrix.ssl }}
if: ${{ matrix.ssl && matrix.ssl != 'stock' && steps.cache_ssl.outputs.cache-hit != '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
run: env ${{ matrix.ssl }} scripts/build-ssl.sh
- name: Install OpenTracing libs
if: ${{ contains(matrix.FLAGS, 'USE_OT=1') && steps.cache_ot.outputs.cache-hit != 'true' }}
run: |
OT_PREFIX=${HOME}/opt-ot scripts/build-ot.sh
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
- name: Build WURFL
if: ${{ contains(matrix.FLAGS, 'USE_WURFL=1') }}
run: make -C 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
- name: Compile HAProxy with ${{ matrix.CC }}
run: |
echo "::group::Show platform specific defines"
echo | ${{ matrix.CC }} -dM -xc -E -
echo "::endgroup::"
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
make -j$(nproc) all \
ERR=1 \
TARGET=${{ matrix.TARGET }} \
CC=${{ matrix.CC }} \
DEBUG="-DDEBUG_STRICT -DDEBUG_MEMORY_POOLS -DDEBUG_POOL_INTEGRITY" \
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
${{ join(matrix.FLAGS, ' ') }} \
ADDLIB="-Wl,-rpath,/usr/local/lib/ -Wl,-rpath,$HOME/opt/lib/"
sudo make install
- name: Show HAProxy version
id: show-version
run: |
echo "::group::Show dynamic libraries."
if command -v ldd > /dev/null; then
# Linux
ldd $(which haproxy)
else
# macOS
otool -L $(which haproxy)
fi
echo "::endgroup::"
haproxy -vv
echo "::set-output name=version::$(haproxy -v |awk 'NR==1{print $3}')"
- name: Install problem matcher for VTest
# This allows one to more easily see which tests fail.
run: echo "::add-matcher::.github/vtest.json"
- name: Run VTest for HAProxy ${{ steps.show-version.outputs.version }}
id: vtest
run: |
# This is required for macOS which does not actually allow to increase
# the '-n' soft limit to the hard limit, thus failing to run.
ulimit -n 5000
make reg-tests VTEST_PROGRAM=../vtest/vtest REGTESTS_TYPES=default,bug,devel
- name: Show VTest results
if: ${{ failure() && steps.vtest.outcome == 'failure' }}
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
run: |
for folder in ${TMPDIR}/haregtests-*/vtc.*; do
printf "::group::"
cat $folder/INFO
cat $folder/LOG
echo "::endgroup::"
done
shopt -s nullglob
for asan in asan.log*; do
echo "::group::$asan"
cat $asan
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
echo "::endgroup::"
done