Auto detect IaC provider based on files in infra folder

[jongio]

Right now we'll require setting the infra provider in azure.yaml

Instead of doing that,

Let's inspect the infra folder.

If bicep files, then use bicep, if tf files, then use tf, if both, then prompt the user to update the azure.yaml file.

[ellismg]

What about just making bicep the default and having terraform be something you have to opt into, instead of this file system sniffing?

[jongio]

@ellismg that is what we have today. I like the idea of the user doing less work and azd sniffing as a convention

[spboyer]

Current State

• pathHasModule only checks if a module file exists, but doesn't detect provider type from file extensions
• Provider defaults to Bicep when not specified in azure.yaml
• No automatic detection based on file types in the infra folder

Proposed Solution

Add a detectProviderFromFiles function that:

1. Scans the infra directory for .bicep, .bicepparam, .tf, and .tfvars files
2. Returns bicep if only Bicep files found
3. Returns terraform if only Terraform files found
4. Returns error with clear message if both found, prompting user to specify in azure.yaml
5. Returns NotSpecified if no IaC files found (fallback to existing behavior)

Update ProjectInfrastructure to:

1. First respect explicit infra.provider in azure.yaml (backward compatible)
2. If not specified, call detectProviderFromFiles for auto-detection
3. Continue with existing infrastructure discovery logic

Benefits

• ✅ DRY: Single function (~40 lines) handles all detection logic
• ✅ Minimal code changes: One new function, one modification to existing function
• ✅ Non-breaking: Explicit config still honored, only activates when provider not specified
• ✅ User-friendly: Clear error when ambiguous (both providers present)
• ✅ Follows existing patterns: Similar to CI/CD provider detection in pipeline_manager.go

No Deprecation Needed

Auto-detection becomes the primary mechanism, not a transitional feature. Users never need to specify provider in azure.yaml unless they want to override or resolve ambiguity.

Implementation Details

The detection logic will be inserted in cli/azd/pkg/project/importer.go in the ProjectInfrastructure function, after resolving the infraRoot path and before checking for layers or modules. This ensures:

• Explicit configuration takes precedence
• Auto-detection happens early in the flow
• All downstream logic remains unchanged

[vhvb1989]

the ProjectInfrastructure is part of the ImportManager. It also knows how to pull infra-files from specific importers, like Aspire (dotnetImporter).

Based on that, we could add a new importer for auto-detection with what @spboyer has defined.