GitLab

Also sort "VENDOR-VERSION-ARCH" variables.

This reverts commit d1c81e86.

krb5 1.18.2 was promoted to the "updates" repository.

Fedora's 'updates-testing' repository has fixed version of the krb5
package. Lets install it for the sake of 'tsiggss' and 'nsupdate'
system tests.

Also drop other (unused) Linux distributions.

Pointing to repos in $(CENTOS_MIRROR_BASE_URL)/7/ namespace means using
always the latest CentOS 7 repos (7.8 at this point), even if the install
ISO was CentOS 7.7. A more version-specific repos should be used during
the installation.

Current backtraces from cores produced by system tests miss a lot
information on Alpine Linux. Adding the 'musl-dbg' package makes them on
par with the rest of C libraries. Addition size is about 3 MB.

The combination of current CentOS/EPEL 7 versions of mock and GPGME
triggers the following error when YUM invoked by mock running in a
Docker container attempts to verify repository metadata:

    gpgme.GpgmeError: (7, 32870, u'Inappropriate ioctl for device')

This prevents any CentOS 7 RPM packages from being built in GitLab CI.
Work around the problem by forcing mock to run YUM without a PTY
attached.

YUM for CentOS 6 does not support the "ip_resolve" configuration option,
so the tweaks applied in the Dockerfile are not fully effective.
Furthermore, hardcoded file paths make those tweaks prone to breaking
due to package updates.  It is also simpler to disable IPv6 globally
after creating a Docker container than trying to patch all places where
it can potentially be used at image build time.

The "tzdata" Ubuntu package is no longer a dependency of any of the
packages we install on that system.  Make sure it always gets installed
by explicitly including it in the list of packages to install on
Debian/Ubuntu, so that the "time_test" BIND unit test can pass.

As we plan to at least update the Python QA tools used for BIND in
GitLab CI after each BIND release goes public, add Debian buster to the
list of operating system whose images are rebuilt on a monthly basis to
make sure any potential issues caused by OS updates are caught in due
time.

With the introduction of Python-based system tests in BIND, all
operating system images used in GitLab CI should now have pytest and the
"requests" module installed.  Additionally, the pip tool should also be
available to facilitate prototyping tests in merge requests by
eliminating the need to install pip in each CI job.

Otherwise, "pip install" fails.

One of the dependencies of the Cloudsmith CLI now needs this package.

The python-dnspython package was dropped from Debian "sid" and thus can
no longer be installed on that system.  Since this move is a part of a
larger initiative to remove Python 2 from Debian, there is little sense
in trying to implement Dockerfile workarounds for this specific package.
Instead, remove Python 2 packages from all our Debian Docker images
except the "buster" one (to retain some Python 2 test coverage for BIND
branches other than "master").

docker/bind9/ubuntu-template symlinks to docker/bind9/debian-template,
so GitLab CI will never trigger any Ubuntu jobs automatically unless the
symlink itself changes.  Ensure Ubuntu jobs are triggered when
docker/bind9/debian-template is modified, to reflect actual Dockerfile
dependencies.

Out of all i386 Docker images we are currently building, only the "sid"
one is actively being used in GitLab CI.  Remove all other i386 images.

  - Automatically start jobs for all images potentially affected by a
    Dockerfile template change or a Packer source file modification.
    The rationale here is that most meaningful changes to image contents
    happen through modifications to Dockerfile templates and Packer
    source files while Makefile updates are rare (and starting all
    relevant jobs when a Makefile is modified would be reckless).

  - Allow all jobs to be run (on demand) for pipelines created through
    the web interface.  This allows any build job to be tested before
    merging a branch which modifies Makefile(s) but does not touch any
    Dockerfile templates or Packer source files (since Makefile changes
    alone do not trigger build jobs).

  - Automatically push rebuilt images to the production Docker registry
    when a branch is merged into "master".  Propagating changes
    introduced by branches which only touch Makefile(s) will require
    creating a pipeline for the "master" branch using the web interface,
    but that is expected to be needed rarely.

  - Ensure scheduled build jobs are still run automatically.

Packer jobs should also benefit from parallel compilation the way Docker
jobs do.  This only applies to FreeBSD jobs for the time being (since we
do not compile any source code while building other QCOW2 images), but
make the necessary adjustments on a "global" level (in packer/Makefile)
anyway, so that further platforms can be tweaked more conveniently if
the need arises in the future.  While packer/freebsd/packer.json only
allocates 2 vCPUs to the VM building the QCOW2 image and the default
number of parallel build jobs is set to 6, we do not care much about
that discrepancy.