When a template is configured with prebuilds, we terraform apply the template first to provision the prebuild using the prebuilds identity, and then once more once it has been claimed by a user.

The second apply could result in resources being replaced if the resource definition relies upon the identity.

Example:

resource "google_compute_instance" "dev" {
  count        = data.coder_workspace.me.start_count
  name         = "coder-${lower(data.coder_workspace_owner.me.name)}-${lower(data.coder_workspace.me.name)}-root"
  ...

Upon first apply the name of this resource will be coder-prebuilds-prebuild-1234-root, the second one coder-danny-myfirstworkspaceyay-root. GCP and other providers generally do not allow resource names to be reconfigured after provisioning, so the resource would be replaced with a new one, obviating the benefit of prebuilds.

There are many situations under which a replacement could occur, not just for the name attribute, and it's impossible to warn upfront comprehensively.

In the current implementation we're detecting this replacement and providing a warning, but this may be missed by template admins.

We may need to augment the template import process to allow for prebuild validation.

This would entail creating a prebuild imperatively and performing a terraform plan using a new identity to determine the proposed changes. This would incur some cost, but it's likely negligible.

The flow could be something like this:

1. Template admin imports a new template/version
2. Prebuilds are detected
3. Popup appears offering to validate prebuild configuration
4. "OK" is pressed, kicking off the provisioning of a prebuild
5. The UI follows the logs and waits for the workspace to provision
6. Once completed, it runs a terraform plan with a different identity injected, to detect replacements
7. If found, UI displays warnings for all resource attributes which will cause a replacement, and offer docs / advice on how to rectify (i.e. add ignore_changes)