Closed Baarsgaard closed 10 months ago
@koushik-swaminathan Sorry to ping you, but I would love to have this reviewed to continue using the provider :)
@Baarsgaard sure, I'll take a look. Have you tested these changes?
Yes, all of it is tested.
Luckily very little of the actual business logic has changed.
The only new code is the resourceOpsGenieNotificationPolicyMultiValueValidation()
function in the 3rd commit, the rest is refactoring and Schema validation updates.
LGTM, tested it as well. But it looks like it doesn't really fix the conditions in-place issues, but time-restriction seems to be stable now.
Could you share what specifically does not work? I've been testing with a fair amount of notification policies and I'm unable to get the perpetual state drift to show up:
Hi @Baarsgaard, the in-place issue was persisting in my local but it seems to work for you. LGTM, approving the PR.
I'll set it for Monday next week 2023-11-06
@koushik-swaminathan Should be ready for a merge now! :D
LGTM, tested it as well. But it looks like it doesn't really fix the conditions in-place issues, but time-restriction seems to be stable now.
I was thinking about what could be the cause of this. The difference is likely that the policies I created were saved as a set, but your test was made on policies stored as the old list.
If you run terraform apply -refresh-only
followed by a normal terraform apply
is the plan still unstable?
Commits:
Closes #246
Closes #253 And #409 And adds some much needed schema validation for Terraform-ls to use.
Closes #341: Unifies the Schema, Input-Validation, and
expanding/flattening
fortime_restriction
blocks. This implementation should fix unstable plans containingtime_restriction
for all resources.225 only addressed a single resource.
Closes #355 Way stricter input validation of actions before
terraform apply
This is a pretty big PR solely because of the
time_restriction
refactor, I am willing to split it, but I do still think reviewing this PR one commit at a time is feasible.