Google Secret Manager, Field Option #185
Conversation
stvnksslr
changed the title
|
Hi @stvnksslr, Thank you for your pull request! Your contribution is much appreciated. 😄 I noticed that the CI tests have failed for this pull request. Could you please take a look? If you have any questions or need assistance with resolving the test failures, feel free to ask. We're here to help! |
|
@kaplanelad hey yeah I ran into one small wrinkle in trying to test this specific functionality would appreciate some direction. The test helper seems to always include the field attribute for all providers, previously for the Google secret manager provider ignored the field attribute as it had no way to parse K:V/json formatted secrets. I'm not sure how to provide testing for the original functionality and the new functionality without creating a new test helper that allows field to be passed optionally. But that feels like a far more disruptive change than I was intending. I am also open to a different approach on tracking this field if needed but this seemed to fit into the mold of the other providers fairly well. |
|
Not super happy with the solution I came up with but I think it better illustrates what I was talking about. |
|
@kaplanelad would you be able to approve the test suite to run when you are able and review the changes. |
Related Issues
#184
Description
Allow the fields key to be used to do K:V matches between google secret manager bodies that contain json as required by many kubernetes ecosystem tools.
Motivation and Context
This allows similar functionality to many of the other providers that are more key value based for secrets.
How Has This Been Tested?
I have tested this locally and will be adding additional tests to the provider suite.
Checklist