Discovered while reviewing #51 (PR environments). The storage module in #37 generates the storage account name in env-config from `project + app + environment` without any workspace prefix:
```hcl
infra/{{app_name}}/app-config/env-config/storage.tf
storage_account_name = substr(
"${replace(lower("${var.app_name}${var.environment}"), "/[^a-z0-9]/", "")}st${substr(md5(...), 0, 8)}",
0, 24
)
```
When PR-environment #51 spins up workspace `p-<pr_number>`, `terraform apply` in that workspace will try to create the same storage account name as the `default` workspace, and Azure will reject it (storage account names are globally unique across all subscriptions).
Why workspace-prefixing doesn't work for Azure
AWS solves this by prefixing the bucket name with the workspace (`p-42-mybucket`). Azure storage account names cap at 24 lowercase-alphanumeric characters — `p-42-` is invalid (contains `-`), and even `p42` consumes scarce length on a name that already includes a 24-char-truncated hash.
Recommended fix
Share the dev storage account across PR-environment workspaces, mirroring how the database is shared. The `is_temporary` plumbing already exists from #37; extend it so non-default workspaces read the storage account from the default workspace's state rather than creating their own.
Possible implementations:
- A `terraform_remote_state` data source pointing at the default workspace, gated on `is_temporary`
- A data source (`azurerm_storage_account`) that looks up the existing account by deterministic name when `is_temporary = true`
- A boolean `create_storage_account` flag passed to the module
The doc added in #51 (`docs/infra/pull-request-environments.md`) already establishes the pattern: PR envs share certain resources with dev. Storage should be added to the list once this is fixed.
Why this is filed against #37 and not #51
PR #51 (PR environments) doesn't directly cause the bug; #37's storage module just doesn't account for non-default workspaces. The fix belongs in #37 or as a follow-up to it. #51 will be merge-ready independently.
Discovered while reviewing #51 (PR environments). The storage module in #37 generates the storage account name in env-config from `project + app + environment` without any workspace prefix:
```hcl
infra/{{app_name}}/app-config/env-config/storage.tf
storage_account_name = substr(
"${replace(lower("${var.app_name}${var.environment}"), "/[^a-z0-9]/", "")}st${substr(md5(...), 0, 8)}",
0, 24
)
```
When PR-environment #51 spins up workspace `p-<pr_number>`, `terraform apply` in that workspace will try to create the same storage account name as the `default` workspace, and Azure will reject it (storage account names are globally unique across all subscriptions).
Why workspace-prefixing doesn't work for Azure
AWS solves this by prefixing the bucket name with the workspace (`p-42-mybucket`). Azure storage account names cap at 24 lowercase-alphanumeric characters — `p-42-` is invalid (contains `-`), and even `p42` consumes scarce length on a name that already includes a 24-char-truncated hash.
Recommended fix
Share the dev storage account across PR-environment workspaces, mirroring how the database is shared. The `is_temporary` plumbing already exists from #37; extend it so non-default workspaces read the storage account from the default workspace's state rather than creating their own.
Possible implementations:
The doc added in #51 (`docs/infra/pull-request-environments.md`) already establishes the pattern: PR envs share certain resources with dev. Storage should be added to the list once this is fixed.
Why this is filed against #37 and not #51
PR #51 (PR environments) doesn't directly cause the bug; #37's storage module just doesn't account for non-default workspaces. The fix belongs in #37 or as a follow-up to it. #51 will be merge-ready independently.