terraform-provider-azurecaf
terraform-provider-azurecaf copied to clipboard
Add support for updates to resource type(s) with auto-upgrade support
Signed-off-by: Owen Farrell [email protected]
Fixes #140 Supercedes: #196
PR Checklist
- [x] I have read the CONTRIBUTING.MD instructions
- [ ] I have changed the
resourceDefinition.json
- [ ] I have generated the resource model (there's a
models_generated.go
file in my PR) - [ ] I have updated the README.md#resource-status
- [x] I have checked to ensure there aren't other open Pull Requests for the same update/change?
Description
Does this introduce a breaking change
- [ ] YES
- [x] NO
While this doesn't inherently introduce a backwards-breaking change, I'm not sure that my attempt at an auto-upgrade is a sure thing. The approach that I used was a bit of a "guess and check" based on the existing outputs. In a worst case scenarios, anyone who attempts to auto-upgrade will incur the existing behavior (a forced deletion/recreation of downstream resources) one last time. Any suggestions on how to mitigate this issue would be appreciated.
Testing
In addition to local unit testing, I've exercised these updates via a local provider override and it seems to meet the need.
$ make build
go generate
2022/11/02 12:22:28 File generated
go fmt ./...
azurecaf/data_environment_variable.go
azurecaf/models_generated.go
azurecaf/provider_test.go
go build -o ./terraform-provider-azurecaf
go test ./...
? github.com/aztfmod/terraform-provider-azurecaf [no test files]
ok github.com/aztfmod/terraform-provider-azurecaf/azurecaf 24.284s
? github.com/aztfmod/terraform-provider-azurecaf/completness [no test files]
SonarCloud Quality Gate failed.
0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells
No Coverage information
26.7% Duplication
any update on this enhancement? this would save a lot of headaches for folks who didnt notice this behavior and encountered significant cascading impacts (resource re-creation)