The sidecar uses a read-only filesystem which prevents Python from
creating bytecode at runtime. The previous approach pre-compiled
bytecode in a separate base image, but timestamps were corrupted
when files were copied between Docker stages, causing Python to
mark the bytecode as stale and recompile on every invocation.
This change builds Python dependencies as wheels in a pythonbuilder
stage using BuildKit cache mounts, then installs them in the final
python:3.13-slim-trixie stage using a bind mount. Wheels include
pre-compiled bytecode with correct timestamps. The bind mount keeps
wheels out of final layers, and the distroless complexity is
eliminated.
After wheel installation, we run compileall to ensure all Python
bytecode is freshly compiled with correct timestamps, preventing
any stale bytecode from remaining in the final image.
The separate barmanbase image, its workflow, and related Renovate
configuration are no longer needed and have been removed.
Closes#711Closes#735
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
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>
We should ignore the go.mod files in renovate that are inside the
dagger directory, these go.mod files should be updated using
the proper `dagger update` command
Closes#305
Signed-off-by: Jonathan Gonzalez V. <jonathan.gonzalez@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Co-authored-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Switch to building documentation in markdown, avoiding the
markdown+html hybrid we have.
Closes#250
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Rework the Dockerfile to list Python dependencies.
Those can be updated using renovate.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Co-authored-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Avoid automatic update of dagger module go.mod. It should be updated on
dagger updates.
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Group all the dagger modules coming from the sagikazarmark/daggerverse
repo in a single renovate PR. This prevents single commits in that repo
to cause multiple PRs in this one.
Closes#118
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Limit the amount of PRs opened by renovate and also do not auto
rebase the PRs to avoid consuming all the GitHub Runners
Signed-off-by: Jonathan Gonzalez V. <jonathan.gonzalez@enterprisedb.com>
