Skip to content

feat: ship the testbed assets as a Go module - #397

Open
aepfli wants to merge 1 commit into
mainfrom
feat/go-embed-module
Open

aepfli wants to merge 1 commit into
mainfrom
feat/go-embed-module

Conversation

@aepfli

@aepfli aepfli commented Sep 14, 2026

Copy link
Copy Markdown
Member

This PR

Adds a root Go module, github.com/open-feature/flagd-testbed/v3, that embeds the testbed assets: the compose stack, the Gherkin suites, the flag definitions and the test root certificate.

Why

Consumers embed this repository as a git submodule. That works for an SDK repository testing itself, but it breaks down for a test framework that wants to be distributed — a Go module cannot carry a submodule of another repository, so anything built on the testbed has to re-do the checkout wiring, and the shared step definitions in go-sdk-contrib/tests/flagd cannot be consumed as an ordinary dependency.

With the module, a Go suite depends on a released testbed through go.mod, and renovate updates it like any other dependency:

// Compose runners take the stack as a reader - nothing is unpacked.
compose.NewDockerComposeWith(compose.WithStackReaders(bytes.NewReader(testbed.ComposeYAML())))

// godog reads the suites straight from the embedded FS.
godog.Options{FS: testbed.Gherkin(), Paths: []string{"."}}

Materialize(dir) is there for runners that need the stack on disk.

Notes for review

  • The module path carries the /v3 suffix, as Go requires at major version 2 and above. The upside is that the existing release tags double as module versions, so release-please needs no changes at all. The cost is a path rename at v4.0.0 — which downstream has to react to on a major testbed bump anyway.
  • Tags cut before this commit carry no root go.mod and therefore cannot be resolved as /v3 module versions. The first consumable version is the next release.
  • No dependencies, deliberately: the module does not constrain the testcontainers or Cucumber versions of the suite consuming it.
  • ssl/custom-ca.key is not embedded. It is only needed to build the image, and a private key has no business travelling into consumers' module caches. Only the certificate does.
  • The nested launchpad module is excluded from the root module automatically, so the launchpad sources are not shipped.
  • A test asserts that the compose file's ${VERSION:-vX.Y.Z} default matches version.txt. release-please stamps them independently, and a consumer pinning the module gets the wrong image if they ever disagree.
  • CI gains a go job. It also runs the launchpad tests, which were not running anywhere before.

Verified against a consumer

go-sdk-contrib was flipped over in open-feature/go-sdk-contrib#962 (draft, blocked on this PR): submodule removed from .gitmodules, the framework reading the stack, suites and certificate from this module, resolved from a pseudo-version through the proxy. The testbed comes up and 310 scenarios execute with no checkout of this repository anywhere. That branch also shows what the version jump from the pinned 3.8.0 to 3.10.1 costs the Go provider — two changed configuration defaults and ~40 steps with no definitions — but that is adoption work, unrelated to this PR.

Consumers embed this repository as a git submodule, which works for a repo
testing itself but not for a test framework that wants to be distributed: a
Go module cannot carry a submodule of another repository, so every suite built
on the testbed has to re-do the checkout wiring.

Add a root Go module that embeds the compose stack, the Gherkin suites, the
flag definitions and the test root certificate, so Go suites can depend on a
released testbed through go.mod instead. The module has no dependencies, and
leaves the choice of compose runner and Cucumber implementation to the consumer.

The CA key is deliberately left out - it is only needed to build the image.

The module path carries the /v3 suffix required for major versions >= 2, so the
existing release tags double as module versions. Tags cut before this commit
have no root go.mod and are therefore not resolvable as /v3 module versions;
the first consumable version is the next release.

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
@aepfli
aepfli requested a review from a team as a code owner September 14, 2026 07:26
@coderabbitai

coderabbitai Bot commented Sep 14, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 67ff552d-f1e6-4074-a15a-ae8c57fc34c1


Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant