Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate against resource naming rules declared in swagger #1679

Closed
stan-sz opened this issue Mar 2, 2021 · 8 comments
Closed

Validate against resource naming rules declared in swagger #1679

stan-sz opened this issue Mar 2, 2021 · 8 comments
Labels
enhancement New feature or request

Comments

@stan-sz
Copy link
Contributor

stan-sz commented Mar 2, 2021

There's a documented list of resource naming rules: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules

Describe the solution you'd like
Bicep could (when possible) warn about breaking the naming rules. Lightly related to #1453

@stan-sz stan-sz added the enhancement New feature or request label Mar 2, 2021
@ghost ghost added the Needs: Triage 🔍 label Mar 2, 2021
@alex-frankel
Copy link
Collaborator

@tfitzmac - do you know how that doc is put together? Is it entirely autogenerated?

@alex-frankel alex-frankel changed the title Validate against resource naming rules Validate against resource naming rules declared in swagger Mar 4, 2021
@alex-frankel alex-frankel added this to the v0.4 milestone Mar 4, 2021
@tfitzmac
Copy link

tfitzmac commented Mar 4, 2021

@alex-frankel - no, I populated as much as I could with rules from the swagger files, but that was not complete. At this point, it is just maintained manually.

@majastrz
Copy link
Member

majastrz commented Mar 4, 2021

@alex-frankel I think it'll be beneficial to drive some changes through the swagger ecosystem to make this more consistent E2E. We could get new linters built to require naming rules on resource names to be specified (similar to other changes we're driving for what-if), for example.

@stan-sz
Copy link
Contributor Author

stan-sz commented Jun 2, 2021

I just hit the problem of exceeding one of the limits... It would have saved me quite a bit of time if this was caught by Bicep. If this was to be coded in a linter, then that linting rule would have to be by default an error (to prevent from deploying something that would fail anyway).

"error": {
    "code": "VaultNameNotValid",
    "message": "The vault name '...' is invalid. A vault's name must be between 3-24 alphanumeric characters. The name must begin with a letter, end with a letter or digit, and not contain consecutive hyphens. Follow this link for more information: https://go.microsoft.com/fwlink/?linkid=2147742"
  }

@alex-frankel
Copy link
Collaborator

Should this be part of the linter? I would think this should be part of the core type definitions. At that point, this would show as a warning because we deem the swagger specs unreliable, but we could expose a build command to treat warnings as errors.

@masters3d
Copy link
Contributor

I think this should be part of bicep. For example I have run into issues when using the region name as part of the resource name and finding out that some regions like australia break the build because the name is too long. Perhaps the linter could also catch these by suggesting folks to use a seeded name based on subid, region, rg

@dazinator
Copy link

dazinator commented Oct 8, 2022

From the perspective of someone getting started with bicep, being able to see some information as to what the naming rules are, would be my main want - fancier stuff like compile time checks (errors, warnings, suggestions) or auto conpletions that use good practices, etc would be bonus.

@jeskew
Copy link
Contributor

jeskew commented Dec 18, 2023

This work was completed in Azure/bicep-types-az#1454 & #9870. Bicep should be warning about resource names that will fail validation when deployed as of version 0.21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants