Azure publisher uses "environmentName" parameter for resourceGroupName

[eerhardt]

When generating the main.bicep file in the Azure publisher, we use a parameter named environmentName and use it to generate the resource group name:

aspire/src/Aspire.Hosting.Azure/AzurePublishingContext.cs

Lines 69 to 70 in 6a3c091

	var environmentParam = new ProvisioningParameter("environmentName", typeof(string));
	MainInfrastructure.Add(environmentParam);

aspire/src/Aspire.Hosting.Azure/AzurePublishingContext.cs

Lines 86 to 91 in 6a3c091

	var rg = new ResourceGroup("rg")
	{
	Name = BicepFunction.Interpolate($"rg-{environmentParam}"),
	Location = locationParam,
	Tags = tags
	};

There are 2 things about this that are surprising:

1. It is always prefixed with rg-. Do people always need/want their Resource Group to be prefixed with rg-?
2. The parameter name "Environment Name" is too ambiguous. It probably comes from azd's concept of an environment when you azd init.

We should consider changing this code:

1. Name the parameter resourceGroupName
2. Drop the mandatory prefix rg- and just use the resourceGroupName directly.

cc @davidfowl @captainsafia @tg-msft @vhvb1989 @mitchdenny

[vhvb1989]

IIRC, for AZD we are trying to follow the Azure best practices (https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming#naming-considerations) which includes using a prefix.

We could probably add a comment or something about it, but I wouldn't remove it

[eerhardt]

Maybe it could be an option to include the prefix. I'm not sure always forcing it is the right answer. Especially if someone is already including the rg- prefix in the parameter. Then they just need to strip it before passing it in.

[davidfowl]

Name the parameter resourceGroupName

Seems like the right approach.

[vhvb1989]

Name the parameter resourceGroupName

Seems like the right approach.

EnvironmentName is the name we chose for AZD, but the idea behind it is not to name the resourceGroup.
The main deeper idea behind this parameter is for users to introduce a constat that makes the deployment deterministic.

If you think about a world without AZD, you would still have a parameter like 'name' or 'userApplicationInstance' which is used in combination with rg, sub to produce the unique suffix to auto-name resources.

Without this strategy, you have more chances to get into naming conflicts. Without a way to name or reference your deployment as one snapshot or instance, you will also face challenges when trying to re-deploy.

And one last thing is that if you mapped the name to resource group, you will face a challenge the moment you need to support multi-rg deployments