Fixed incorrect secret creation on drift detection of secret value#2499
Fixed incorrect secret creation on drift detection of secret value#2499jorgecarleitao wants to merge 1 commit intointegrations:mainfrom
Conversation
nbali
left a comment
There was a problem hiding this comment.
yeah, pretty much what I had in mind, ty for your time
|
Please let us know when this fix will be merged. |
|
This issue is making me reconsider the use of Terraform to manage repository secrets, or split secrets into a new configuration. We create a placeholder secret and ignore the changes, so the team can update the secrets and we will not detect a drift. |
|
I built the latest version of the provider and cherry picked your 1 commit on the "fix" branch. It works like a dream. |
|
@nbali This is a really big issue. Any ETA. |
|
@jacobkretz-bf I'm not sure why are you mentioning me :) I just suggested a solution to the issue, that @jorgecarleitao essentially implemented. |
|
@kfcampbell What does it take to get this PR approved and released? |
|
Bumping this again as this is something that is impacting getting clean plans. |
|
Seems like an "approving review" is required to merge this PR. When can we expect this patch to land in the source tree? |
Resolves #1383
Resolves #2288
Before the change?
Given a .tf with a resource with any secret
When .tf is applied
And the secret's value is externally modified
And .tf is applied
Then the new plan results in the creation of a new secret
After the change?
Given a .tf with a resource with any secret
When .tf is applied
And the secret's value is externally modified
And .tf is applied
Then the plan results in the update of the existing secret
In particular, this behavior enables the use of the lifecycle meta argument to ignore changes to externally updated secrets.
Pull request checklist
NOTE: I could not find any test that I could re-use to introduce an external change to an existing resource. Need support.
Does this introduce a breaking change?
Please see our docs on breaking changes to help!