PipelinePolicy model, fixtures, and basic happy-path test

[crstrn13]

Parent

Part of #974 — Extensions SDK testing: PipelinePolicy

Context

PipelinePolicy is an out-of-tree Kuadrant extension built with the Extensions SDK. The extension is pre-installed on the test cluster via the helm chart — no deployment or CRD installation is needed from the testsuite side. This issue covers the Python model class, pytest fixtures, and a basic smoke test.

What needs to be done

1. PipelinePolicy Python class

Create testsuite/kuadrant/extensions/pipeline_policy.py following the existing pattern (see oidc_policy.py, plan_policy.py):

• Subclass Policy
• create_instance(cluster, name, target, ...) builds the CR model
• Methods to add actionMethods, request actions, and response actions to the spec
• Use @modify decorator on mutating methods
• Group: extensions.kuadrant.io/v1alpha1, Kind: PipelinePolicy

2. Fixtures

Create a conftest with fixtures for:

• Creating a PipelinePolicy resource targeting the test HTTPRoute
• Configuring request and response actions for the test scenarios
• Standard testsuite fixtures (route, hostname, client, etc.)

3. Basic happy-path test

A smoke test that validates the extension is working end-to-end:

1. Create a PipelinePolicy targeting an HTTPRoute with:
   • A simple allow request action (e.g., request.url_path != "/blocked")
   • An add_headers response action (e.g., add x-pipeline-policy: active)
2. Send a request to an allowed path → expect 200 + x-pipeline-policy: active header
3. Send a request to /blocked → expect 403 (denied by the allow action)

4. Test location

testsuite/tests/singlecluster/extensions/pipeline_policy/
├── conftest.py                         # PipelinePolicy fixtures
└── test_pipeline_policy_basic.py       # Happy-path tests

5. Pytest markers

pytestmark = [pytest.mark.extensions]

Acceptance criteria

• PipelinePolicy class in testsuite/kuadrant/extensions/pipeline_policy.py
• Fixtures create and clean up PipelinePolicy resources
• Basic happy-path test passes: allow action blocks /blocked, permits other paths
• Response headers from add_headers action are present
• Tests are marked extensions
• make commit-acceptance passes

[SurbhiAgarwal1]

Hi @crstrn13, I’ve been going through the related extension testing issues and this one looks like a good entry point for understanding the testsuite patterns and the Extensions SDK flow more deeply.

I started reviewing some of the existing policy implementations and fixtures (like oidc_policy.py and related tests) to better understand the expected structure and resource lifecycle handling.

The separation here between:

• the policy model,
• reusable fixtures,
• and the happy-path validation flow

looks like a really good way to establish the baseline for future extension test coverage as well.

I’d be interested in working on this issue if it’s available. Please let me know if there’s anything specific I should review first before getting started.

[crstrn13]

Hey @SurbhiAgarwal1, unfortunately I am going to pick this up as the extensions SDK are still in-development and a lot of moving parts that require coordination and a better understanding of the ecosystem. Feel free to pick anything labeled with good first issue or something that you feel might be good place to start. Unfortunately, the extensions SDK isn't, I am sorry