Conformance tests are created to guarantee that an implementation, regardless of its language, backend technology, etc behaves as expected with Gateway API specifications.
As of today, our conformance tests are written in Go and can be compiled, but this is not straightforward as:
- Some timeout configuration may vary between implementations and environments, and they are hard coded
- There is no binary generation, so this means that implementations still needs to checkout the code and compile localy
- Some other options are not even exposed to users, so some implementations have a fork of conformance to suit their needs
As a form of making conformance more generic, tied to a specific tagged version but also portable, we could:
- Expose the user-facing configurations of
|
type ConformanceOptions struct { |
to be configurable via a YAML (eg.: mark the fields of this structure with a yaml tag, allow users to pass a flag with a place where this configuration should be read from)
- Do not override configurations that were already previously passed as flags - priority of merging configurations is flags first, then yaml to keep compatibility
- Do not expose all fields of this configuration structure. as an example, the Kubernetes client is constructed from the flags
On other words, this change MUST NOT be a breaking change. Instead it should make it easier to expose configurable fields but keep the same working behavior as if this configuration option never existed in case implementations opt to not use it.
Lately, as part of the release, compiling the conformance as a binary (and eventually releasing as a container) would be helpful for implementations, but this can be covered on another issue
Conformance tests are created to guarantee that an implementation, regardless of its language, backend technology, etc behaves as expected with Gateway API specifications.
As of today, our conformance tests are written in Go and can be compiled, but this is not straightforward as:
As a form of making conformance more generic, tied to a specific tagged version but also portable, we could:
gateway-api/conformance/utils/suite/suite.go
Line 135 in 2fe7137
On other words, this change MUST NOT be a breaking change. Instead it should make it easier to expose configurable fields but keep the same working behavior as if this configuration option never existed in case implementations opt to not use it.
Lately, as part of the release, compiling the conformance as a binary (and eventually releasing as a container) would be helpful for implementations, but this can be covered on another issue