Skip to content

Assertions on published connection details secrets #82

@ulucinar

Description

@ulucinar

What problem are you facing?

Connection details secrets published by the managed resources are part of an MR's public API and we currently don't consider them in uptests.

How could Uptest help solve your problem?

We could include the connection details secret fields in the provider documentation (not related to uptest) and we could add support in uptest so that:

  • We can assert resource-specific schema on the published connection details secrets as part of our tests (to make sure that certain info is published in a certain format in the connection details secret of a certain resource). Another example would be to prevent the removal of an existing field in the connection details secret with a new provider release and consider this as a breaking change (something we currently don't check with crddiff or schemadiff).
  • Look for double-encoded fields in connection secrets.
  • ...

In summary, we could increase the test coverage in our public APIs if we start implementing tests for our connection details secrets. Ideally, we could implement generic tests (like the double-encoding checks mentioned above) as well as allowing hooks for resource-specific tests.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions