mirror of
https://github.com/zalando/postgres-operator.git
synced 2026-09-30 14:22:47 +02:00
3b6dc4f92d
* icnrease vm size * cache deps * switch to the absolute cache path as cdp does not support shell expansion * do not pull non-existing image * manually install kind * add alias to kind * use full kind name * one more name change * install kind with other tools * add bind mounts instead of copying files * test fetching the runner image * build image for pierone * bump up the client-go version to match the master * bump up go version * install pinned version of kind before any test run * do not overwrite local ./manifests during test run * update the docs * fix kind name * update go.* files * fix deps * avoid unnecessary image upload * properly install kind * Change network to host to make it reachable within e2e runner. May not be the right solution though. * Small changes. Also use entrypoint vs cmd. * Bumping spilo. Load before test. * undo incorrect merge from the master Co-authored-by: Sergey Dudoladov <sergey.dudoladov@zalando.de> Co-authored-by: Jan Mußler <janm81@gmail.com>
Postgres Operator end-to-end tests
End-to-end tests shall ensure that the Postgres Operator does its job when
applying manifests against a Kubernetes (K8s) environment. A test runner
Dockerfile is provided to run e2e tests without the need to install K8s and
its runtime kubectl in advance. The test runner uses
kind to create a local K8s cluster which runs on
Docker.
Prerequisites
Docker Go
Build test runner
In the directory of the cloned Postgres Operator repository change to the e2e folder and run:
make
This will build the postgres-operator-e2e-tests image and download the kind
runtime.
Run tests
In the e2e folder you can invoke tests either with make test or with:
./run.sh
To run both the build and test step you can invoke make e2e from the parent
directory.
Covered use cases
The current tests are all bundled in test_e2e.py:
- support for multiple namespaces
- scale Postgres cluster up and down
- taint-based eviction of Postgres pods
- invoking logical backup cron job
- uniqueness of master pod
- custom service annotations