Well done, for soldering on with this. Really appreciate it!

Maybe worth to slice a pull request 1. secretmanager 2. parameter?

Sorry for the merge conflicts 🙇 I hope they aren't bad!

Other than these there will no change to AWS providers until this is done, I promise.

Heyy @Skarlso I totally understand, This is taking more time than I had anticipated mostly because work has been quite busy these past few weeks 😅

Maybe worth to slice a pull request 1. secretmanager 2. parameter?

That's a good point but I need to check if there's some common code that both of these depend on. We'll split the PR after evaluating that. Thank you :)

Thanks a lot @Skarlso !

/ok-to-test sha=7e62ccf8192e6c865106618d94790d38353f21c4

Once the tests are done, I'm going to put back enableSessionCache with a deprecation note, because it's breaking anyone's startup if it's removed suddenly. And we learned from 0.17.0 that even release notes won't help that. :P So we are going to give it a grace period of a couple releases.

[Bot] - ✅ e2e for 7e62ccf8192e6c865106618d94790d38353f21c4 passed

Okay, so this all looks fine for me. One last test I want to perform is how about existing things.

I'll have a bunch of secrets with various tags and names and finds and dataFrom's created with old implementation. And the point is that it needs to behave the same way so that it stays backwards compatible once I switch over to v2. @Ilhan-Personal did you do some testing like that by any chance?

Also, this is a major update, so I'm wondering how to hell do we release this without causing chaos. If we really would want to be backwards compatible, it would mean duplicating somehow the provider. Basically, create a v2 provider. Take the current code. Make a new provider. Call it aws secrets manager | parameter store v2 and tell people to use that if they are adventurers. :) @gusfcarvalho what do you think? Do we just release this...? I mean it looks okay, it works the same way on the surface, and I'll perform some backwards checks ( create shit with v1, then switch over to this branch and see if things are still okay ). WDYT?

Tbh, tests passing, and given we didn’t change our tests that much, I think we can release this as a patch even. If something broke; then we fix it. But we have no reason to believe this will be breaking for users. It shouldn’t in almost any aspect (maybe the small api changes on pointer/non pointer?🤔).

in any case, I think this doesn’t really require a minor bump 😃

I know we might have some regression here and there 🤷🏽‍♂️ but tbh we cannot release based on things we don’t know.
From what we know, this should be a patch users won’t even feel

If it would help move things along, we could assist with testing by rolling it into our medium sized setup (about 500 distinct deployment environments)

We would have to spend a day or two validating the changes before rolling it into production. So not sure if how that fits into your timelines.

@lukaspj That would be insanely appreciated! I tested with existing setup, but not like a larger thing with several scenarios. I can't test that. :) It would be very very helpful if you could do that please. :)

Ah unfortunately, I wasn't aware that v1beta1 had been removed in v0.17 and we have a couple of thousand external secrets we need to update so I can't promise that we can do this in due time :(.

Very unfortunate

Ah, no worries then. I'll do some testing on my side then.

I'll have a bunch of secrets with various tags and names and finds and dataFrom's created with old implementation. And the point is that it needs to behave the same way so that it stays backwards compatible once I switch over to v2. @Ilhan-Personal did you do some testing like that by any chance?

Heyy @Skarlso, I unfortunately did not do that but I'll be happy to run this locally and do what you mentioned sometime tomorrow if that works

Sure, we can both verify it to see that everything works fine. :)

Everything is synced...

➜ k get pushsecret,externalsecret -A
NAMESPACE   NAME                                                AGE   STATUS
default     pushsecret.external-secrets.io/pushsecret-example   26s   Synced

NAMESPACE   NAME                                                       STORETYPE     STORE                REFRESH INTERVAL   STATUS         READY
default     externalsecret.external-secrets.io/aws-secretsmanager-es   SecretStore   aws-secretsmanager   1h                 SecretSynced   True
default     externalsecret.external-secrets.io/example                 SecretStore   aws-secretsmanager   1h                 SecretSynced   True

Switching to this branch...

...

➜ k get pushsecret,externalsecret -A
NAMESPACE   NAME                                                AGE     STATUS
default     pushsecret.external-secrets.io/pushsecret-example   2m54s   Synced

NAMESPACE   NAME                                                       STORETYPE     STORE                REFRESH INTERVAL   STATUS         READY
default     externalsecret.external-secrets.io/aws-secretsmanager-es   SecretStore   aws-secretsmanager   10s                SecretSynced   True
default     externalsecret.external-secrets.io/example                 SecretStore   aws-secretsmanager   10s                SecretSynced   True

Everything remained in-sync. Yay. :)

Deleting pushsecret also removed the remote secret. ✅

Testing parameter store as well... Everything synced up. :) Nice ✅

Quality Gate passed

Issues
0 New issues
1 Accepted issue

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarQube Cloud

@Ilhan-Personal Thank you so much for the hard work! This was one amazing job! :) 🙇 I tested it as much as I can, so hopefully, we don't have any breaking changes. Nevertheless I want to release this in a minor version in 0.18.0 later. :)

Hopefully, people can now start doing some AWS stuff, and see some updates being made and new regions being available. :) 🤞

Hi!
Firstly, thank you for your amazing work on this PR!
I saw that it's planned to be included in version 0.18.0.
Do you have an estimated timeline for when this release might happen?

@Ilhan-Personal @Skarlso

Somewhere next week, hopefully. We need to fix a very weird release bug before we release any other versions.

so you should expect a 0.18.0-rc1 (and maybe rc2, rc3, rc4) before we actually cut 0.18.0

Fixed #3319, too.