Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assertions on published connection details secrets #82

Open
ulucinar opened this issue Mar 16, 2023 · 0 comments
Open

Assertions on published connection details secrets #82

ulucinar opened this issue Mar 16, 2023 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@ulucinar
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants