These are definitions for podman-based integration tests for the
DaCHS software.


Test harnesses
--------------

We have one directory per scenario.  There are two classes of scenarios:

(a) install-x, which pull up the entire DaCHS thing (including postgres)
    as part of the test run
(b) upgrade-x, which do the installation (including postgres) during the
    container setup and exercise the apt update/upgrade.


The basic test harness for installing is install-local-package, which
you want to run before uploading the packages, while it's still
reasonably simple to re-do the whole package.

All these containers execute a shell script docker-init, which has to
arrange for postgres startup and DaCHS installation; that's typcially
slightly different for the different harnesses.  It then hands over
to dachstest.sh, which must run with no DaCHS running and as the
dachsroot user created by the package.

Derived install- containers will in general override docker-init but
probably not dachstest.sh.


Building and executing
----------------------

Once you've set up podman, enter the directory with the test harness and
say::

  ../update-container
  ../exec-container

Note: At least for now, podman build (as executed by
../update-container) doesn't run with namespaced unix ports. This means
that for now you must stop the host's postgres to build the upgrade-X
containers.

For upgrade-* containers, there's some extra work to be done because we
want to keep containers for upgrading::

  podman images | grep upgrade-beta
  # run upgrade containers like this (from any subdirectory):
  ../exec-container upgrade-beta-2.5.6
  # With the last one, while it's still running, execute
  dockerbased/commit-upgrade-container beta 2.7

Remove old upgrade containers using ``podman rmi -f <name>``.

That's it if things work well. But podman still sometimes doesn't work
all that great, in particular in rootless mode. Crib sheet:

* "cannot set user namespace". Removing ~/tmp/libpod helps. Please don't ask.


Configuration Variables
-----------------------

docker-init (and various other things) use some environment variables:

* PGVERSION – used by docker-init to start and stop the right postgres
  cluster.  This must always match the version in the Debian release to
  be tested.
* DACHS_SUITE – in install-X, this is the GAVO suite to pull DaCHS from;
  that's either beta or release at this point.

Data
----

Most containers use data taken from DaCHS' live RDs. That's in the
test-inputs subdirectory. The RDs are pulled in through svn:externals,
and there is the test data Markus uses on his box in
test-inputs/test-data.

The test data is inserted into the data-less resdirs through symlinks
set up in test-inputs/test-script. If you add data, you will have to add
these symlinks in the test-script, too, and you'll have to arrange for
the data to be imported, too.

All this stuff is mounted as /var/gavo-inputs in the containers by the
exec-container script (I keep this outsider of /var/gavo, as that is
only created once the container is up in some containers). The trouble
is that that leads to unusable permissions inside of the container,
which I'm currently fixing in the docker-init. Having the inputs
directory in a non-standard place means that it needs to be configured
in /etc/gavo.rc.