You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Applying these manifests produces two entries into 1Password Vault. At first the PushSecret object shows everything being ok but on the next sync it changes into Errored state
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Synced 5m59s (x2 over 5m59s) pushsecret PushSecret synced successfully
Warning Errored 2m14s (x16 over 4m58s) pushsecret set secret failed: could not write remote ref foo to target secretstore 1pass: expected one 1Password Item matching:
'test-foo-secret', got 2
Running on following versions:
External-Secrets: `0.9.12`
```sh
$ kubectl --namespace external-secrets get deployment external-secrets --output jsonpath={.spec.template.spec.containers[0].image}
ghcr.io/external-secrets/external-secrets:v0.9.12
Expected behavior
I would expect to have only one entry in 1Password. Instead I'm getting two.
Screenshots
Additional context
During my testing I think I have gotten only 1 entry in 1Password occasionally, and I'm fairly sure I got 3 at some point too. So either it doesn't seem to be fully deterministic or I happened to change some things to different position.
This feature was just released in 0.9.12 and implemented in the following PR #2646.
The text was updated successfully, but these errors were encountered:
Describe the bug
Sometimes
onepassword
/PushSecret
creates multiple entries to 1Password.To Reproduce
Secret/1pass-token
in the namespacePushSecret
object shows everything being ok but on the next sync it changes intoErrored
state'test-foo-secret', got 2
Kubernetes:
v1.27.8-gke.1067004
Expected behavior
I would expect to have only one entry in 1Password. Instead I'm getting two.
Screenshots
Additional context
During my testing I think I have gotten only 1 entry in 1Password occasionally, and I'm fairly sure I got 3 at some point too. So either it doesn't seem to be fully deterministic or I happened to change some things to different position.
This feature was just released in
0.9.12
and implemented in the following PR #2646.The text was updated successfully, but these errors were encountered: