Use a fork of the k3s dagger module that adds:
- Optional debug parameter (defaults to false) to disable k3s server debug logs
- Optional kubeletVerbosity parameter (defaults to 1) for kubelet log control
This eliminates verbose output from both k3s server (certificate generation,
database init) and kubelet (container operations, volume cleanup) while
maintaining visibility of errors and warnings.
Kubelet verbosity is controlled via a configuration file placed in the k3s
config directory before kubelet initializes, avoiding the logging configuration
immutability issue.
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>
Pin crd-ref-docs to v0.2.0 (latest stable release) instead of using the
master branch. This prevents issues from upstream changes and provides
better control over when to adopt new versions.
Configure Renovate to automatically track and update the version,
allowing us to review and test changes before merging.
Closes#722
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This PR adds a disclaimer to the object stores documentation clarifying
that the Barman Cloud Plugin does not independently test all
authentication methods supported by barman-cloud. The plugin's
responsibility is limited to passing the provided credentials to
barman-cloud, which then handles authentication according to its own
implementation.
This documentation change was decided by the maintainers as part of the
discussion around Azure Default Credentials support (#662).
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This commit adds support for the DefaultAzureCredential authentication
mechanism in Azure Blob Storage. Users can now use the
`useDefaultAzureCredentials` option to enable Azure's default credential
chain, which automatically discovers and uses available credentials in
the following order
1. Environment Variables (Service Principal)
2. Managed Identity
3. Azure CLI
4. Azure PowerShell
This is particularly useful when running on Azure Kubernetes Service
(AKS) with Workload Identity, eliminating the need to explicitly store
credentials in Kubernetes Secrets.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This change fixes Azure credentials validation to require a storage
account when using explicit credentials such as a storage key or SAS
token, and ensures the connection string is mutually exclusive with
other authentication parameters.
Closes#705
Related: cloudnative-pg/barman-cloud#177
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Follow-up to #700 to align the targetTime documentation with
cloudnative-pg standards. The note now covers all timestamp formats (not
just RFC 3339) and uses PostgreSQL format in the example to avoid
advertising the non-standard RFC3339-like format without timezone. A
warning has been added recommending to always specify an explicit
timezone to avoid ambiguity.
Related: #699
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Update the machinery dependency to include the fix that ensures
RFC3339-like timestamps without timezone (e.g., "2024-01-15T10:30:00")
are interpreted as UTC.
The documentation has been updated to use a targetTime example with an
explicit Z suffix and to clarify that RFC3339-like timestamps without timezone
are interpreted as UTC.
Closes#699
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Logging the full environment of the plugin container can potentially
result in an unnecessarily long log line, but perhaps more importantly
the credentials are visible as well.
Signed-off-by: Andreas Mårtensson <andreas.martensson@svt.se>
