288c0772e6
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. |
||
|---|---|---|
| .github | ||
| contrib | ||
| doc | ||
| examples | ||
| include | ||
| reg-tests | ||
| scripts | ||
| src | ||
| tests | ||
| .cirrus.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| BRANCHES | ||
| CHANGELOG | ||
| CONTRIBUTING | ||
| INSTALL | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
| ROADMAP | ||
| SUBVERS | ||
| VERDATE | ||
| VERSION | ||
README
The HAProxy documentation has been split into a number of different files for ease of use. Please refer to the following files depending on what you're looking for : - INSTALL for instructions on how to build and install HAProxy - BRANCHES to understand the project's life cycle and what version to use - LICENSE for the project's license - CONTRIBUTING for the process to follow to submit contributions The more detailed documentation is located into the doc/ directory : - doc/intro.txt for a quick introduction on HAProxy - doc/configuration.txt for the configuration's reference manual - doc/lua.txt for the Lua's reference manual - doc/SPOE.txt for how to use the SPOE engine - doc/network-namespaces.txt for how to use network namespaces under Linux - doc/management.txt for the management guide - doc/regression-testing.txt for how to use the regression testing suite - doc/peers.txt for the peers protocol reference - doc/coding-style.txt for how to adopt HAProxy's coding style - doc/internals for developer-specific documentation (not all up to date)