Make it possible to use endpoints to containers, projects or dockerfiles in bicep parameters

[davidfowl]

Follow up from https://github.com/Azure/azure-dev/pull/3820

The main scenario here is a webhooks. External services that need to call your compute (e.g. Azure event grid, azure web pubsub etc)

var builder = DistributedApplication.CreateBuilder(args);

var p = builder.AddProject<Projects.WebApplication1>("webapplication1");

var az = builder.AddAzureStorage("storage")
                .WithParameter("z", () => p.GetEndpoint("http"))
                .RunAsEmulator().AddQueues("q1");

builder.Build().Run();

Results in

module storage 'storage/storage.module.bicep' = {
  name: 'storage'
  scope: rg
  params: {
    location: location
    principalId: resources.outputs.MANAGED_IDENTITY_PRINCIPAL_ID
    principalType: 'ServicePrincipal'
    z: 'http://webapplication1.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }
  }
}

Notice the go template syntax in the bicep. This should just use the bicep value instead of the go template (when in this context).

Instead we want:

module storage 'storage/storage.module.bicep' = {
  name: 'storage'
  scope: rg
  params: {
    location: location
    principalId: resources.outputs.MANAGED_IDENTITY_PRINCIPAL_ID
    principalType: 'ServicePrincipal'
    z: 'http://webapplication1.${resources.outputs.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN}'
  }
}

[ellismg]

Going to be interesting to consider what happens if there's a reference to something like .targetPort, which we would need to compute eagerly instead of waiting until deploy.

I think that's the only value in our reference syntax that we support today that we may not know at bicep generation time.

[davidfowl]

Going to be interesting to consider what happens if there's a reference to something like .targetPort, which we would need to compute eagerly instead of waiting until deploy.

Fail in this case.

We also fail if you reference a bicep secret output as a parameter so there's prior art