pretecno/crowdsec-bouncer-traefik-plugin

mirror of https://github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin.git synced 2026-07-21 11:38:59 +02:00

Files

T

mhx 45abab69ec 🐛 tests: set CROWDSEC_BYPASS_DB_VOLUME_CHECK for v1.7+

Crowdsec v1.7 refuses to start without an explicit volume mount on
/var/lib/crowdsec/data (or the bypass env var). For E2E we don't need
db persistence — set the bypass everywhere so the stack boots.

2026-06-06 12:03:19 +02:00

lib

✨ tests: end-to-end suite scaffold + stream-mode scenario

2026-06-06 12:03:19 +02:00

scenarios

🐛 tests: set CROWDSEC_BYPASS_DB_VOLUME_CHECK for v1.7+

2026-06-06 12:03:19 +02:00

README.md

✨ tests: end-to-end suite scaffold + stream-mode scenario

2026-06-06 12:03:19 +02:00

README.md

End-to-end test suite

These tests spin up real Traefik + Crowdsec containers and exercise the plugin in the same conditions Traefik uses in production: loaded from a local path, no module download, no mocking.

Each scenario lives in its own directory under scenarios/ and owns:

docker-compose.yml — the stack to spin up
run.sh — orchestration + assertions
optional fixtures (acquis.yaml, ban.html, ...)

Running locally

Prerequisites: docker, docker compose, curl, bash.

Run a single scenario:

./tests/e2e/scenarios/stream-mode/run.sh
# or
make e2e_stream-mode

Run everything:

make e2e

Each scenario uses an isolated Docker Compose project (-p e2e-<scenario>), so multiple scenarios can run in parallel without colliding on container names — except for the crowdsec container, which keeps its canonical name so cscli commands work uniformly across scenarios. Run scenarios serially if you need to invoke them on the same host at the same time.

Writing a new scenario

Copy scenarios/stream-mode/ as a template.
Rename container_names (keep crowdsec for the LAPI container).
Edit run.sh to express the behavior under test.
Add the scenario name to the matrix in .github/workflows/e2e.yml and to E2E_SCENARIOS in the Makefile.

CI

.github/workflows/e2e.yml runs one parallel job per scenario on every PR and push to main. On failure, container logs are uploaded as an artifact named logs-<scenario>.