Open asilverman opened 2 years ago
Today, naming requirements are not a part of our resource type definitions, though they are sometimes present in swagger, so it would be possible to use that info in our type system. I think we'd also need to add some type information about the type of string that is returned (i.e. string that could start with letter or number).
Related: #1679
One fairly straightforward possibility is to include the naming regex in the generated description during type generation.
Bicep version
Bicep CLI version 0.4.1124 (66c84c8ee5)
Describe the bug
I was recently attempting to instantiate a bicep resource with a randomly generated name for the purpose of my ci testing process. The name of the resource is constrained (as a Azure policy) to start with a letter.
I inadvertently set the name using
uniqueString()
, however it turns out this function doesn't guarantee that the result will start with a letter, and the bicep vscode extension didn't warn me about this fact while authoring the resource.This results in me creating a deployment that will periodically fail introducing flakiness to my CI environment since every now and then (given that I am recreating the environment on each build) I may get a uniqueString that starts with a number resulting in a bad request error.
I am curious if there's a way to have the vscode linter/static-analyzer detect this during authoring since its unreasonable to expect authors to "just know" what are the constraints on a particular azure resource name.
Here is the resource I was setting:
Here is the sporadic error I would get every now and then:
Here is how I ended up fixing the issue:
Expected Behavior I would expect the Bicep VSCode extension to underline the stanza
name: uniqueString('foo')
with a warning or an error that indicates that doing this is unsafe.