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

for each file in a directory #3607

Open
skyaddict opened this issue Jul 14, 2021 · 4 comments
Open

for each file in a directory #3607

skyaddict opened this issue Jul 14, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@skyaddict
Copy link

skyaddict commented Jul 14, 2021

With the creation of #471 there will be the ability to load content from a file. The next logical step would be to allow for each file in a folder. The file object returned should include FullName, BaseName, parent dir. Wildcarding would also be helpful. *.xls, *.liquid, etc.

Potentially something like Get_ChildItem from PowerShell.

foreach ($file in Get-ChildItem '$(Pipeline.Workspace)/Infrastructure/Schemas')

Example: I create an integration account and then need to load the Maps and schemas into this integration account. I could see something like

module map 'IntegrationAccount/IntegrationAccountMap.bicep' = [for file in getFiles('integrationAccount/maps'): {  
  scope: resourceGroup()
  name: file.BaseName
  params: {
    integrationAccountName: IntegrationAccount.outputs.name
    mapName: file.BaseName
    filePath: file.FullName
    mapType: 'Liquid'
  }
}]

Today an object with each file path and name listed does the trick, however having this be more dynamic would be excellent. and avoid missing things when they get added.

@scott1138
Copy link

This has a lot of use cases as parameter files can become very clunky after a few hundred lines. Our App Gateway parameters are very unwieldy so I am moving the config to Bicep and storing each application configuration in it's own json file. Then I am loading that file in the main.bicep and passing the appropriate config to the required module. It would be extremely helpful to not have 20 load statements and to continuing adding them with every new config

@kamilzzz
Copy link

This would be really useful in some scenarios, although one would need to be careful to not exceed the ARM deployment engine size limit when loading bunch of files from directory.

Scenarios:

  • subscription vending machine - each subscription could be defined as a separate JSON/YAML file and then loaded and iterated by the Bicep deployment (this is something Terraform supports and Terraform implementation for Azure subscription vending module mentions in their documentation)
  • API Management APIs could be defined the same way - similar to what @scott1138 mentions above with App Gateway, just imagine you are part of a platform team and provide some central services where you have more and more APIs/Apps exposed by shared APIM/AppGateway
  • sometimes this would be useful even for simpler scenarios where you just want to improve some readability, for example, I needed to deploy multiple APIM policies to our instance, I didn't want them to be hardcoded in Bicep so externalized them by storing XMLs in the repo, however I needed to load them one by one in Bicep anyway

@mindingdata
Copy link

+1 for this as it's a scenario we are also finding.

We are utilizing APIM with several different APIs and Endpoints. We currently have a Swagger + Policy file for each API, and this is loaded by using the file load capability that is now in Bicep. However, when new APIs are added, we would like to rely on folder conventions to simply load in the API as it's added, essentially removing the need for someone to edit the main bicep file each time.

@nayanshah
Copy link

I hit the same problem while generating AppInsights alerts using json config files. My workaround is to generate a .bicep file before the compilation step that references all the config files in the alerts directory.

Example: https://gist.github.com/nayanshah/7c86cfe6c9882c9e8133cee6ce17c9bb

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

6 participants