Guide for building, testing, and contributing to Praxis ExtProc.
- Rust stable 1.94+ (edition 2024)
- Rust nightly (for
rustfmt;group_importsandimports_granularityare nightly-only) - Docker or Podman (container builds)
- KIND (local Kubernetes testing)
make build # cargo build
make release # cargo build --release
make test # cargo test
make lint # clippy + nightly fmt check
make fmt # cargo +nightly fmt
make doc # rustdoc with -D warnings
make audit # cargo audit + cargo deny check
make container # build container imageRun a single test:
cargo test -- test_namesrc/
lib.rs # Crate root, module declarations
bin/
praxis_extproc.rs # Binary entry point, CLI, startup
adapter.rs # ExtProc ↔ Praxis type translation
config.rs # YAML config loading, pipeline build
error.rs # Error types (thiserror)
health.rs # gRPC health check service
metrics.rs # Prometheus metrics endpoint
response.rs # ProcessingResponse builders + chunking
server.rs # ExternalProcessor gRPC implementation
tls.rs # TLS configuration
tests/
grpc_server.rs # In-process gRPC server tests
services.rs # Health and metrics service tests
integration.rs # Kubernetes integration tests
examples/
praxis-extproc.yaml # Example ExtProc configuration
envoy.yaml # Example Envoy configuration
branch-chains.yaml # Branch chain example
deploy/
namespace.yaml # Kubernetes namespace
configmap.yaml # ConfigMap with ExtProc config
deployment.yaml # Deployment manifest
service.yaml # Service manifest
envoyfilter.yaml # Istio EnvoyFilter for ExtProc
echo.yaml # Echo backend for testing
gateway.yaml # Istio Gateway for testing
httproute.yaml # HTTPRoute for testing
hack/
kind-config.yaml # KIND cluster configuration
setup-kind.sh # KIND cluster setup script
smoke-test.sh # End-to-end smoke test
teardown-kind.sh # KIND cluster teardown
Set up a full local environment with Istio and the ExtProc server deployed:
make dev-envThis creates a KIND cluster, installs Istio, deploys the ExtProc server, and configures an EnvoyFilter to wire Envoy's ext_proc filter to the server.
After the initial setup, rebuild and redeploy:
make dev-pushThis rebuilds the container image, loads it into KIND, and restarts the deployment.
Run integration tests against the running cluster:
make dev-integrationRun end-to-end verification:
make smoke-testTear down:
make kind-down| Variable | Default |
|---|---|
KIND_CLUSTER_NAME |
praxis-extproc |
EXTPROC_IMAGE |
praxis-extproc:dev |
make testUnit tests are embedded in each source module. They cover config parsing, adapter translation, response building, body chunking, and TLS configuration.
tests/grpc_server.rs starts the ExtProc server
in-process and exercises the full gRPC stream
lifecycle: request headers, request body, response
headers, response body, trailers, and rejection
scenarios.
tests/services.rs tests the health and metrics
auxiliary services independently.
Require a running Kubernetes cluster with Istio and the ExtProc server deployed:
make test-integrationGated behind the integration feature flag. These
tests verify end-to-end behavior through Envoy's
ext_proc filter in a real cluster.
Run with verbose output:
make test-integration V=1make containerMulti-stage build using rust:1.94-alpine for
compilation and alpine:3.22 for the runtime image.
The binary is statically linked against musl and
stripped. The runtime image runs as a non-root user.
GitHub Actions workflow (.github/workflows/tests.yaml)
runs on every push and pull request:
- Format check (
cargo +nightly fmt --check) - Clippy (
cargo clippy -- -D warnings) - Tests (
cargo test) - Doc build (
RUSTDOCFLAGS="-D warnings" cargo doc) - Audit (
cargo audit,cargo deny check)
All repositories in the praxis-proxy organization
use a consistent workflow for planning, prioritizing,
and tracking work.
Milestones represent a body of work toward a shared goal (e.g. a release, a feature area, or a hardening pass). Every issue and pull request should belong to a milestone. Milestones provide scope boundaries and help answer "what ships together?"
Priority labels indicate the order in which work within a milestone should be addressed. Every issue should have exactly one priority label:
| Label | Description |
|---|---|
priority/critical |
Must be worked on immediately before anything else |
priority/high |
Needs to be worked on immediately, defer to criticals |
priority/medium |
Resolve after high and critical |
priority/low |
Resolve after all other priority levels |
When picking up work, address issues in priority order: critical first, then high, medium, and low.
GitHub project boards visualize the state of work across milestones. Use boards to track issues through their lifecycle (backlog, in progress, in review, done). Boards are the primary tool for stand-ups and status checks.
See conventions.md for the full coding standards, including file ordering, test conventions, separator comment format, and documentation requirements.