It doesn't make sense to call these scripts "before install" because
they do actually install things themselves.
In fact the whole separation into "install" and "before build" is
probably not very useful, but keep it as long as we keep using Travis CI
at all, as it maps better to its config file keys.
No real changes.
"readline" frontend doesn't work without a controlling TTY as can be
seen by setting DEBCONF_DEBUG=user before running dpkg-reconfigure, so
use "teletype" instead.
Also note that DEBIAN_FRONTEND environment variable unexpectedly seems
to override the value explicitly passed via dpkg-reconfigure -f option,
so we need to reset it (and then we don't need the -f option at all).
Handle Xenial which is similar to Trusty and also Focal, where we need
to install Firebird 3.0 server and tweak expect command to work with it.
Note that we still use Xenial for GitHub Actions Firebird CI build as
using Focal version results in memory leaks inside Firebird libraries
and there doesn't seem to be a debug symbol package for Firebird 3.0
that would be required to write a suppression file for them.
This fixes the problem with psqlodbca.so not being found by unixODBC in
GitHub Actions environment.
It remains unclear why was this unnecessary on Travis CI and why it
doesn't work out of the box, but without this change we were always
getting
[unixODBC][Driver Manager]Can't open lib 'psqlodbca.so' : file not found (SQL state 01000)
when trying to connect to the database.
Start the service explicitly as this is not done by default.
Also explicitly use password with mysql in GitHub Actions environment,
both for the root and for the current user.
This wasn't necessary on Travis CI but is required in this environment,
so specify the root password explicitly and also create the MySQL user
(which is not hardcoded "travis" any longer) and record its password in
~/.my.cnf.
This fixes Oracle tests after 325ee4e9 (Split build and test stages of
the CI builds, 2021-03-16) which resulted in oracle.sh not being sourced
when running the tests any longer.
This workflow reuses the same CI scripts as the existing Travis CI
config file and, for now, uses Ubuntu 16.04 (Xenial) runner to be as
close to Travis configuration as possible.
While this doesn't matter for Travis CI, it makes sense to separate them
for the other CI systems using more structured approach to the build
steps.
Add a few test_*.sh scripts for the backends that need to do something
special when running the tests and just use run_test function for all
the others.
The term "script" is too generic and really doesn't mean anything,
especially outside of Travis CI context, where "script" is used as the
config file key for the build script to run.
Vadim Zeitlin