Pin all e2e test emulator images to specific SHA256 digests to ensure
immutability and prevent unexpected breakage from upstream changes.
The three emulators (Azurite for Azure, MinIO for S3, and
fake-gcs-server for GCS) were previously using the :latest tag, which
could cause test failures when new versions with breaking changes or
bugs were released.
Using SHA256 digests instead of version tags provides immutability
(ensures we always pull the exact same image), transparency (easy to
verify what's running via digest comparison), and Renovate compatibility
(can still track and propose updates). All pinned SHAs match the current
:latest tag, confirming we're using the same images that were previously
tested.
Updated Renovate configuration to track digest-based updates while
preserving version information in comments for human readability. Fixed
Renovate to scan test directories and handle multi-line regex patterns
for .go files.
Also fixed Azurite compatibility issue by adding the
--skipApiVersionCheck flag. Tests were failing because the PostgreSQL
container images install Python dependencies without version pinning,
which resulted in azure-storage-blob 12.28.0 (released January 6, 2026)
being installed. This version uses API version 2026-02-06 which Azurite
3.35.0 doesn't support yet. The flag allows Azurite to accept any API
version in the test environment.
Note that MinIO is now in maintenance mode and will not receive further
updates, but it has been included for completeness.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Use 17-minimal-bookworm images instead of default ones for all the
tests, except the one where we need barman cloud to check compatibility.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Rework the e2e test to expect a working connection to a cluster when
they start. Developers can create their own clusters and run the tests.
Removed the code used to start kind clusters within the e2e tests.
Reworked the Taskfile to define two environments where the tests can run:
1. An ephemeral one running within Dagger, using the k3s module, to be
used by the CI.
2. A persistent one created with Kind, requiring the kind binary, to be
used for development and debugging when the ephemeral cluster is not
enough.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Activate backup and restore tests with GCS using the fake-gcs-server
emulator. Use a fork that support partial reads.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Run basic backup and restore tests for the plugin. Use MinIO for S3,
Azurite for ACS and fake-gcs-server for GCS.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Switch from using exec.Command to using kind and docker as libraries, so
tests won't depend on external binaries.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Create the CI and testing infrastructure for e2e testing. Running the ci
task now will push the plugin and sidecar images to a local registry,
start kind, install the CloudNativePG and cert-manager operators, and
then install the plugin-barman-cloud one.
No actual test is implemented.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
