provider/digitalocean: Making user_data force a new droplet

[stack72]

Fixes #3734

user_data is only run on instance first boot, therefore, changing the user_data will have no effect unless the instance is recreated. This follows the same behaviour as an AWS Instance

There is no way in the Digital Ocean UI to change the user_data. So it requires an instance to be recreated

Added an acceptance test to prove that it destroys and then recreates:

make testacc TEST=./builtin/providers/digitalocean TESTARGS='-run=DigitalOceanDroplet_UpdateUserData' 2>~/tf.log
go generate ./...
TF_ACC=1 go test ./builtin/providers/digitalocean -v -run=DigitalOceanDroplet_UpdateUserData -timeout 90m
=== RUN   TestAccDigitalOceanDroplet_UpdateUserData
--- PASS: TestAccDigitalOceanDroplet_UpdateUserData (76.95s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/digitalocean   76.965s

[phinze]

If you want to prove this was accomplished by a recreate and not an update, I think you'll need to have two different droplet variables and ensure that their IDs are different.

[stack72]

@phinze I must admin that I am not quite sure how I would do that :)

Any pointers to places that do that already in the codebase?

[phinze]

No worries! I'll pull this in as is, tweak it, and highlight you on the commit.

[stack72]

Thanks - this is certainly something that will be useful going forward as I introduce tests when I make changes :)

[phinze]

This sounds good to me! And it matches up with equivalent behavior from other providers.

One proposed addition to the test and then this is good to go. 👍

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.