Add ServiceBus Namespace VNet

[MCKLMT]

No description provided.

[codecov-io]

Codecov Report

Merging #1054 (8d876f7) into main (3682e37) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1054   +/-   ##
=======================================
  Coverage   94.26%   94.26%           
=======================================
  Files         328      328           
  Lines       15811    15811           
  Branches       12       12           
=======================================
  Hits        14904    14904           
  Misses        907      907           

Flag	Coverage Δ
dotnet	94.82% <ø> (ø)
typescript	25.78% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[MCKLMT]

@alex-frankel Any idea why the build fails?

[alex-frankel]

nope.. @anthony-c-martin any idea what's happening? I tried re-running all the jobs yesterday

[miqm]

@MCKLMT - aren't you missing adding the example into playground ts file?

[MCKLMT]

What’s this playground ts file? 🤨

[miqm]

https://github.com/Azure/bicep/blob/main/CONTRIBUTING.md#example-files - bullet no 4

[MCKLMT]

I never modified the playground file for all examples I submitted recently. I will add them. I hope it will fix the build.

[miqm]

Looking closer I don't think it's the problem for the builds failing. It seems like github actions had some internal issue and re-triggered VSIX builds and the third attempt passed, so you should be good with merging.

Although it would be good if we had some check to verify adding examples into playground's ts file so they are visible on the bicep demo webpage. @alex-frankel WDYT?

[alex-frankel]

Although it would be good if we had some check to verify adding examples into playground's ts file so they are visible on the bicep demo webpage. @alex-frankel WDYT?

This would be a good addition, but I am still seeing failed VSIX builds... It looks like there is some kind of retry, but because the earlier tests failed I am not allowed to merge automatically..

[anthony-c-martin]

I think this would be a little clearer to understand with the following:

resource namespaceVirtualNetworkRule 'Microsoft.ServiceBus/namespaces/VirtualNetworkRules@2018-01-01-preview' = {
  name: '${serviceBusNamespace.name}/${virtualNetworkName}'
  properties: {
    virtualNetworkSubnetId: '${virtualNetwork.id}/subnets/${subnetName}'
  }
}

My reasoning:

1. It's just by convention that the name matches the virtualNetwork's name, so feels like it is more understandable to use the variable virtualNetworkname.
2. I feel like it's a good practice to avoid using resourceId() unless absolutely necessary, just because it's easy to mess up with refactors/renames, and this way, the dependency is implicit.

[anthony-c-martin]

Looks great, just a minor suggestion