App Service publishing credentials can't be used as Bicep resource type

[johndowns]

Bicep version
Bicep CLI version 0.3.255 (589f037)

Describe the bug
I'm trying to create an idiomatic Bicep conversion of this JSON template expression:

"[concat(list(resourceId('Microsoft.Web/sites/config', parameters('webapp-name'), 'publishingcredentials'), '2015-08-01').properties.scmUri, '/docker/hook')]"

I have a working version using the resourceId() function (see below), but I've been trying to model this in a more Bicep-native way using existing, and have run into a roadblock. I've tried to use this Bicep code:

resource app 'Microsoft.Web/sites@2019-08-01' existing = {
  name: webappName

  resource publishingCredentials 'config' existing = {
    name: 'publishingcredentials'
  }
}

output url string = '${list(app:publishingCredentials.id, '2019-08-01').properties.scmUri}/docker/hook'

However, the validation complains that the name publishingcredentials isn't valid for the nested config resource (BCP036).

I'm not clear if this is purely an issue with the App Service OpenAPI metadata not including the publishingcredentials name as a type discriminator, or if there's something Bicep could/should be doing differently. For example, it'd be nice if I could override the BCP036 error with the any() function, but I can't.

To Reproduce
Steps to reproduce the behavior:

See above.

Additional context
Add any other context about the problem here.

This code works, but it feels icky:

output url string = '${list(resourceId('Microsoft.Web/sites/config', webappName, 'publishingcredentials'), '2019-08-01').properties.scmUri}/docker/hook'

[alex-frankel]

I'm not clear if this is purely an issue with the App Service OpenAPI metadata not including the publishingcredentials name as a type discriminator

This is the root cause, but we should allow any() to get unblock you. At that point you will lose type validation, but at least you will be unblocked. I will see if I can get someone from the web team to help here.

[alex-frankel]

Turns out this resource type can't be created via PUT only POST. It can be retrieved with a GET, so we'll need to discusss if it is worth supporting as an "existing"-only resource type. Thanks Brian Moore (@bmoore-msft) for doing the digging on this.

Though one change I'd recommend is pulling the apiVersion from the sites resource:

output url string = '${list(resourceId('Microsoft.Web/sites/config', webappName, 'publishingcredentials'), app.apiVersion).properties.scmUri}/docker/hook'

[majastrz]

I think this absolutely makes sense for both the existing syntax and the syntax proposed in #2246. Both are a way of constructing a type-safe reference() function call which is basically a resource GET.

[bmoore-msft]

I don't think publishingCreds can be fetched with a GET only a POST since they are secret (sorry if I misstated that)... so the "feature" in this case would be allowing me to create a resourceId() via the symbolic reference and use it in the list function...

Basically calling list*() without using the resourceId function - so not sure it really changes the feature though...

[majastrz]

I believe the fetching of the secret is still a POST action on an existing resource. I mixed up regular property access in my statement above. Sorry for the confusion ☹.

In this case, both syntaxes are a way of constructing a symbolic name, which then can be used to call a list* method to retrieve the secret in a type-safe way.