Support a property field for the fake provider data

[shuheiktgw]

This PR addresses https://github.com/external-secrets/external-secrets/issues/1269 and adds a property field to the fake provider data. Thank you for your review! 🙂

[ghost]

👇 Click on the image for a new way to code review

• Make big changes easier — review code in small groups of related files

• Know where to start — see the whole change at a glance

• Take a code tour — explore the change with an interactive tour

• Make comments and review — all fully sync’ed with github

  Try it now!

Legend

[gusfcarvalho]

Hi @shuheiktgw ! Thank you for your contribution!

Regarding your implementation, my concern is that this will make the need to set up a property in the Fake provider to make it work. Another option I've been thinking about is to use gjson to actually have the property information encoded into the GetSecret method of the provider (and not change the CRD). You can check the piece of code that does that in GCP provider as an example (https://github.com/external-secrets/external-secrets/blob/main/pkg/provider/gcp/secretmanager/secretsmanager.go#L367-L380).

The idea would be that this Fake Provider definition:

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: fake
spec:
  provider:
    fake:
      data:
      - key: "/foo/bar"
        value: `{"foo":"bar","yada":"yada"}`

Will have the properties foo and yada available.

[gusfcarvalho]

@shuheiktgw any news on this one? If you're out of time, let us know - we can finish this implementation up.

[shuheiktgw]

So sorry that I missed your review 🙇 Let me update the PR as you suggested!

[shuheiktgw]

Hi @gusfcarvalho, sorry it took me so long to fix the PR. I've updated the PR so would you take a look at it? I'm actually not too sure how I should implement the GetSecretMap method for the fake provider so would you guide me on that? 🤔

[gusfcarvalho]

no worries @shuheiktgw ! It also took me a while to take a look at it again!

[gusfcarvalho]

One thing we are also requesting now (like we deployed it yesterday), is that every PR should have a DCO signoff. This means you should commit your code using like git commit -s. If you can sign them off please, we would appreciate it :smile:

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[github-actions[bot]]

This pr is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.