The Ruby flagd provider is the only flagd provider not running the standard OpenFeature flagd-testbed gherkin e2e suite — it uses a bespoke docker/docker-compose.yml + flags.json instead. Every other provider (Go, Java, JS, Python, .NET, PHP) runs the shared harness, so Ruby's behavior isn't validated against the common conformance suite.
What to add:
- Pin the testbed — either the
open-feature/flagd-testbed repo as a submodule (for the gherkin .feature files) or its published container ghcr.io/open-feature/flagd-testbed:vX.Y.Z.
- Wire up
cucumber-ruby to run the shared suites (evaluation.feature, etc.) against a testbed container, with the usual tag exclusions for anything Ruby doesn't support yet (e.g. ~@deprecated).
- Retire the custom
docker/ integration where the shared suite now covers it.
Coordinate with the v2 migration (#209) — the testbed targets current flagd, so running it also surfaces the evaluation.v1 → v2 gap.
The Ruby flagd provider is the only flagd provider not running the standard OpenFeature flagd-testbed gherkin e2e suite — it uses a bespoke
docker/docker-compose.yml+flags.jsoninstead. Every other provider (Go, Java, JS, Python, .NET, PHP) runs the shared harness, so Ruby's behavior isn't validated against the common conformance suite.What to add:
open-feature/flagd-testbedrepo as a submodule (for the gherkin.featurefiles) or its published containerghcr.io/open-feature/flagd-testbed:vX.Y.Z.cucumber-rubyto run the shared suites (evaluation.feature, etc.) against a testbed container, with the usual tag exclusions for anything Ruby doesn't support yet (e.g.~@deprecated).docker/integration where the shared suite now covers it.Coordinate with the v2 migration (#209) — the testbed targets current flagd, so running it also surfaces the
evaluation.v1→v2gap.