ci: Configure SDK compliance harness options

[marandaneto]

Problem

SDK compliance workflows need explicit harness suite/sdk-type selection and configurable blocking behavior so CI only runs the intended contract checks.

Changes

• Point SDK compliance to the harness branch with new workflow inputs.
• Run the capture v0 suite as a server SDK and keep failures non-blocking for now.
• Advertise capture_v0 and encoding_gzip capabilities from the compliance adapter.
• Align local compose with the same suite/sdk type.

Testing

• Parsed workflow YAML.
• Ran dotnet build sdk_compliance_adapter/SdkComplianceAdapter.csproj --no-restore.
• Ran docker compose config for the adapter compose file.
• Ran git diff --check.

Release / changeset

No SDK package changeset: this only changes CI/compliance adapter setup, not the published SDK.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Implemented with Pi using dedicated git worktrees. The change was requested to align SDK compliance harness setup across SDK repositories while keeping non-ready SDKs non-blocking.

[greptile-apps]

Security Review

• Mutable external workflow reference in .github/workflows/sdk-compliance.yml: the reusable workflow is now pinned to a branch name (fix/sdk-harness-options-20260630) in the external posthog-sdk-test-harness repo rather than an immutable commit SHA. Any future push to that branch changes the code executed in CI without a corresponding commit here, creating a supply-chain risk for the workflow runner.

_{Reviews (1): Last reviewed commit: "ci: Configure SDK compliance harness opt..." | Re-trigger Greptile}

[greptile-apps]

Mutable branch reference in reusable workflow

The harness workflow is now referenced by a branch name (fix/sdk-harness-options-20260630) rather than the commit SHA that was here before. Branch refs are mutable — any push to that branch in the external repo will silently change what runs in CI without a corresponding commit in this repository. Once the harness branch is merged (or the needed options land on a tagged release), this should be pinned back to an immutable SHA or version tag to restore the audit trail and prevent unexpected drift.

[github-actions]

posthog-dotnet Compliance Report

Date: 2026-06-30 10:01:52 UTC
Duration: 120768ms

✅ All Tests Passed!

29/29 tests passed

---

Capture Tests

✅ 29/29 tests passed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	213ms
Format Validation.Event Has Uuid	✅	123ms
Format Validation.Event Has Lib Properties	✅	110ms
Format Validation.Distinct Id Is String	✅	109ms
Format Validation.Token Is Present	✅	113ms
Format Validation.Custom Properties Preserved	✅	109ms
Format Validation.Event Has Timestamp	✅	109ms
Retry Behavior.Retries On 503	✅	8121ms
Retry Behavior.Does Not Retry On 400	✅	2117ms
Retry Behavior.Does Not Retry On 401	✅	2114ms
Retry Behavior.Respects Retry After Header	✅	8118ms
Retry Behavior.Implements Backoff	✅	22133ms
Retry Behavior.Retries On 500	✅	6117ms
Retry Behavior.Retries On 502	✅	6118ms
Retry Behavior.Retries On 504	✅	6118ms
Retry Behavior.Max Retries Respected	✅	22132ms
Deduplication.Generates Unique Uuids	✅	117ms
Deduplication.Preserves Uuid On Retry	✅	6117ms
Deduplication.Preserves Uuid And Timestamp On Retry	✅	13126ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	6123ms
Deduplication.No Duplicate Events In Batch	✅	116ms
Deduplication.Different Events Have Different Uuids	✅	112ms
Compression.Sends Gzip When Enabled	✅	109ms
Batch Format.Uses Proper Batch Structure	✅	108ms
Batch Format.Flush With No Events Sends Nothing	✅	106ms
Batch Format.Multiple Events Batched Together	✅	115ms
Error Handling.Does Not Retry On 403	✅	2111ms
Error Handling.Does Not Retry On 413	✅	2113ms
Error Handling.Retries On 408	✅	6117ms