Previously, the https://github.com/Icinga/docker-icinga2 repository was
used to build the Docker images for Icinga 2. However, due to its
various design flaws, the resulted images had limited usability and
required a lot of manual tweaking to make something useful out of them.
This commit now follows our new principles of building Docker images
from the Icinga DB repository, and replaces the old separate repository
with this one. It makes use of the newest Docker BuildKit features to
build the images in a more efficient way, while also granting users full
flexibility to easily extend or modify the images as they see fit
without any issues.
To ensure the workflow is reusable across our repositories, it must support
releasing from different release trains, such as when issuing bugfix or
security releases for older versions alongside newer ones. This change
introduces custom logic to determine when to apply the latest tag and major
version tags. The docker/metadata-action unconditionally applies these tags,
which could override existing greater tags. The new logic compares the current
release tag against all existing tags using semantic versioning rules, a
feature not inherently provided by docker/metadata-action.
Use the checkout action explicitly to fetch all tags, rather than relying on
docker/build-push-action's implicit checkout. This allows us to implement
custom logic for tagging as 'latest' and with the appropriate major version
when applicable.
This workflow builds and publishes container images directly from this
repository. Here is a summary of its initial setup for reference:
The Build and Publish Container Image workflow builds container images and
pushes them to both GitHub Container Registry (GHCR) and Docker Hub. It sets up
QEMU and Docker Buildx for cross-platform builds, and builds the container
images using the Containerfile. Upon pushes to the main branch or when releases
are published, it logs into GHCR and Docker Hub using credentials from GitHub
secrets, tags and pushes the images to both registries, and generates and
pushes signed build provenance attestations to each registry. The workflow also
triggers for pull requests to the main branch, verifying only the image build.
This commit intruduces a small helper class that wraps any writer and
provides a flush operation that performs the corresponding action if the
writer is an AsyncJsonWriter and does nothing otherwise.
Replacing invalid UTF-8 characters beforehand by our selves doesn't make
any sense, the serializer can literally perform the same replacement ops
with the exact same Unicode replacement character (U+FFFD) on its own.
So, why not just use it directly? Instead of wasting memory on a temporary
`String` object to always UTF-8 validate every and each value, we just
use the serializer to directly to dump the replaced char (if any) into
the output writer. No memory waste, no fuss!
The Array, Dictionary, and Namespace types provide a Freeze() method that makes
them read-only. So far, there was the possibility to call some methods with
`overrideFrozen=true` which would then bypass the corresponding check and allow
modification of the data structures nonetheless.
With 24b57f0d3a222835178e88489eabd595755ed883, this possibility was already
removed from the Namespace type. However, for interface compatibility, it kept
the parameter and just ignores it, throwing an exception on any modification on
a frozen instance.
The only place using `overrideFrozen` was processing of the `-D`/`--define`
command line flag that allows setting additional variables in the DSL. At the
time it is evaluated, there are no user-created data structures yet that could
be frozen, so the only frozen objects that could be encountered are Namespaces
(Icinga doesn't freeze other types by itself) and for these, `overrideFrozen`
already has no effect.
Hence, there is no harm in removing `overrideFrozen` altogether. This
simplifies the code and also means that frozen objects are now indeed read-only
without exceptions, allowing further optimizations regarding locking in the
future.
Within the GNU/Linux distribution specific installation guides, the "Set
up Icinga DB" section was only excluded for openSUSE. However, since
there is an openSUSE installation guide within Icinga DB[^0], this is
not consistent. Thus, the if-guard was removed, resulting in this
section being available for each distribution. Windows is already
excluded through an if-guard above.
Some cases for Fedora were missing, which were also added.
[^0]: https://icinga.com/docs/icinga-db/latest/doc/02-Installation/openSUSE/
