Add Helm chart install steps next to kubectl, for the current docs and
the 0.13.0 and 0.14.0 versioned snapshots.
Pin the chart's image tag to the plugin version on older releases. The
chart ships after the plugin, so its own version numbers don't map to
ours, and we skip the pin on the latest release since the chart already
defaults to itself there.
On the current docs, make clear the Helm tab installs the latest
release, not a main-branch build. Only kubectl can test a main-branch
build.
Closes#351
Signed-off-by: Krypton <root@krypton.ninja>
Signed-off-by: danishedb <danish.khan@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: danishedb <danish.khan@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The sidecar's lockfile (`containers/sidecar-requirements.txt`) was being
regenerated with whatever python3 happened to be on the contributor's
machine, drifting from the python3.13 venv the sidecar image actually
ships (this surfaced in #1090, where the lockfile ended up regenerated
with Python 3.12). Adds a `task pip-compile-sidecar` that runs
pip-compile inside a debian:trixie-slim dagger container, the same base
image family the sidecar build uses, so regeneration always targets the
right Python version regardless of the local machine.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Bump barman to 3.20.0 and regenerate the sidecar's pip lockfile with the
same Python 3.13 used by the sidecar's venv.
barman 3.20.0 dropped fake-gcs-server support
(EnterpriseDB/barman#1218), so the GCS backup/restore and
replica-cluster e2e specs are skipped at runtime until that's fixed
upstream.
Also bundles tar into the sidecar image: barman 3.20.0's restore path
now shells out to it, and the distroless base doesn't ship it.
Signed-off-by: Tao Li <tao.li@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The install snippet always linked to the manifest of the latest released
version, regardless of which versioned docs page it was rendered on.
Viewing the 0.13.0 installation page therefore pointed at the 0.14.0
manifest.
Build the manifest URL from the active doc version directly: each
versioned page links its own release tag, and the unreleased "current"
docs link the manifest built off `main` instead of a (nonexistent)
release tag.
---------
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Danish <danish.khan@enterprisedb.com>
Co-authored-by: Danish <danish.khan@enterprisedb.com>
wordlist-ordered is a dep of both spellcheck and uncommitted, which run
in parallel. go-task only writes the checksum after a task's cmds
finish, so both parents could start the task concurrently: the first mv
succeeded and removed .wordlist.txt.new before the second mv ran,
failing CI with "No such file or directory".
Mark the task run: once so concurrent deps are deduped.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
CloudNativePG is moving the bootstrap of new instances from dedicated
Jobs into the instance pod itself (cloudnative-pg/cloudnative-pg#11319):
the restore that used to run in a recovery Job now happens in-process
inside the instance pod before PostgreSQL starts. The sidecar shipped in
that pod must therefore answer the same Restore RPC the operator sends
over the plugin sockets, so the instance mode now registers the
restore-job hooks and advertises the restore-job service capability.
A cluster that only bootstraps from an object store, without continued
archiving, previously received no sidecar at all in its instance pods;
under the new flow that leaves the bootstrap without a plugin socket,
both for the Restore RPC and for `wal-restore` during the recovery
replay. The injection condition is widened to match what the plugin
configuration already considers valid, so recovery-only clusters get the
sidecar too.
The sidecar is dropped once the instance's bootstrap completes
(cluster.Status.CurrentPrimary set), which triggers one deterministic
rollout to remove it, accepted rather than engineered around since it
uses the same switchover/restart machinery as any other pod-spec change.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Regenerates this repo's CODEOWNERS from cloudnative-pg/cnpg-infra's
`componentowners-policy.yaml`, the org's tracked desired state for
CODEOWNERS content.
- Routes ownership through this repo's dedicated GitHub owners team
instead of hardcoded usernames, so membership changes are picked up
automatically.
- Any path-scoped rule now also includes the repo's general owners, so a
path rule adds reviewers rather than silently replacing the `*` rule's
owners for that subtree (CODEOWNERS only honors the last matching
pattern, it does not merge).
See cloudnative-pg/cnpg-infra for the policy this is generated from.
Assisted-by: Claude
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Archive() and the restore job hook each re-derived, on their own,
whether to verify the WAL archive destination is empty, by reading a
Cluster annotation and, for Archive, an on-disk marker file. That
decision belongs to the operator, which already tracks both the
annotation and the marker file's lifecycle.
Honor cnpg-i's new WALArchiveRequest/RestoreRequest field
CheckEmptyWalArchive when the operator sets it: obey it directly,
without re-inspecting the marker file. Only fall back to the previous
annotation-and-marker-file logic when talking to an operator that
predates this field.
Related: cloudnative-pg/cnpg-i#353 adds the field this depends on;
cloudnative-pg/cloudnative-pg#11216 is the operator-side counterpart.
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>
Neither task depends on the other's output: task ci runs lint, tests,
e2e, and docs, while task publish builds and pushes the multi-arch
images. Running them as sequential steps in one job only adds their
durations. Splitting publish into its own job lets it run alongside ci
instead, and lets each job carry only the permissions it actually needs:
ci never writes to the registry, and neither task touches repository
contents, so only packages: write on the publish job remains.
QEMU is only needed for publish, since it's the only job that builds
non-native (arm64) platforms; ci's e2e-ephemeral image build is
amd64-only. The disk cleanup steps aren't needed for publish either: it
only builds two lean multi-arch images, well within the free disk space
available even on the default ubuntu-latest runner.
Note that publishing testing images no longer waits on ci passing, since
gating it away would remove the parallelism this is meant to gain.
Note: main's required status checks are currently ["DCO", "ci"]. A
failure in the new publish job will no longer block merging a PR, since
it isn't in that list (today it does, since publishing is a step inside
the required ci job). Flagging for a decision on whether publish should
be added as a required check.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Co-authored-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
