Testing and Releasing Hext
A release of Hext consists of about 20 binaries. Automation is key. To avoid surprises on release day, all releases are built on each and every push. GitHub Actions is the perfect tool for this task.
Continuous Integration
- hext-ci.sh is triggered on every
pushandpull_request. - Builds and runs libhext’s unit tests in debug mode.
- Checks that the version numbers match in all components of Hext.
- Static analysis with cppcheck.
- Black-box tests for the
htmlextcommand-line utility to ensure that subsequent versions of Hext stay backwards compatible. - Tests for the command-line switches of the
htmlextcommand-line utility. - Blackbox-tests for the language bindings: Python, PHP, Ruby, Node. Consistent behavior of Hext across all language bindings is critical.
- Regression tests for the languages bindings.
Continuous Delivery
- hext-releases.yml is triggered on every
push. - Builds static versions of Boost and Gumbo, because the releases may not depend on anything outside of
glibc. - Uses a cache for dependencies.
- Builds and runs libhext’s unit tests in release mode.
- Builds a Hext Python wheel for each supported Python version on Mac OS and Linux.
- Builds the Hext NPM package containing a static node module for each supported Node version on Mac OS and Linux.
- Uploads all releases as workflow artifacts.
- Tests if each artifact is installable and passes the black-box tests.
Other automation
- Black-box tests are run daily on the “Try Hext in your Browser” section on hext.thomastrapp.com. Additionally, download links must point to the latest release for Hext.
- Hext’s project site is hosted and built on GitHub Pages. It includes the current libhext C++ documentation and the hext.js black-box tests.
- bump-version.sh to increment the version number across all components of Hext.
- make-release.sh to download the latest artifacts and create a new release for NPM and PyPi.
- And lots of others.
Last updated on