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

Support to split template into multiple files? #363

Open
sebader opened this issue Aug 27, 2020 · 15 comments
Open

Support to split template into multiple files? #363

sebader opened this issue Aug 27, 2020 · 15 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@sebader
Copy link
Member

sebader commented Aug 27, 2020

Have you thought about supporting splitting one bicep files into multiple files within the same directory and merging them on build?
I find this a very neat feature in terraform to make larger templates with many resources easier to read - without using modules, that is a different use case for me.

Like:

storageaccounts.bicep
sqldb.bicep
keyvault.bicep

bicep build .
==> my_combined_arm_template.json
@ghost ghost added the Needs: Triage 🔍 label Aug 27, 2020
@alex-frankel alex-frankel added enhancement New feature or request question Further information is requested and removed Needs: Triage 🔍 labels Aug 27, 2020
@alex-frankel
Copy link
Collaborator

Makes sense - it is something we are considering.

Out of curiosity, when do you decide to split code in this way vs using a module?

@sebader
Copy link
Member Author

sebader commented Aug 27, 2020

When working with Terraform I actually do it basically every time. No matter how big or small the project is. I don't know if that is best practice with TF but I would say it is rather common. Happy for other people to comment on this :)
There I usually do use one file per resource type. This is really mostly to keep an easy overview. Instead of scrolling up and down through a long template, you directly navigate to the file, e.g. for all the storage accounts.

Modules on the other hand, are really more about re-using.

@segraef
Copy link

segraef commented Aug 28, 2020

Basically it is a good idea to be able to split files. Be it for an overview, for categorization or just for a better handling. Instead of splitting and simply pointing to a module (or in YAML to a template) is similar but as @sebader already said, modules are more for reusability, scaling and containibility of complexity.

For me root ARM templates linking other child ARM template is almost the same pattern like Terraform root modules (main.tf) referencing child modules.

To be honest, splitting and branching files is a part I don't really like in Terraform but that's just my opinion. But it's also a part of the reason why everyone thinks that JSON ARM files are too big and complex because everything is in a file that has 1000 lines. But let me ask the question differently, what is better, endless switching between folders and subfolders like Terraform or just switching between lines in a file?

@sebader
Copy link
Member Author

sebader commented Aug 28, 2020

But let me ask the question differently, what is better, endless switching between folders and subfolders like Terraform or just switching between lines in a file?

Different people have different preferences - and that's ok! If we would offer the possibility to split files, nobody would be required to do that (just as in Terraform) - but you could if that's what you (and your team) prefers. If we as Microsoft should then recommend one way or the other, that's a different discussion I think.

@jikuja
Copy link

jikuja commented Sep 13, 2020

Some use cases I would use splitting:

  • logic app templates
  • everything which is enter in template as escaped JSON string. E.g. Log Analytivs workbooks.

@JayDoubleu
Copy link

Splitting and loading bicep files would be very useful feature.
As well as functions to load external files and preparing payloads using the bicep language.
Similar to terraform:

  • local variables
  • file function
  • yaml and json decode/encode

Also it would allow for modularity.

@takekazuomi
Copy link
Contributor

Sure, merging local files is a good feature. Take it one step further and support remote git files. That way we can get versioning too. Versioning is a must if you use the bicep file like a module.

@beneshed
Copy link

Seconding this and also liking to add that this would be nice with modules.

For readability it would be nice to seperate a module into a folder with

resource.bicep
params.bicep
variables.bicep
outputs.bicep

@sebbrochet
Copy link

It's a bit unfortunate, ARM JSON files interpreters don't support natively JSON Pointer (RFC 6901) (while we could probably imagine a pre-processor addind it!).

I had recently to compose a lot of JSON "definition" files (of my own) into a single object structure before loading them in memory.
And JSON Pointer definitely helped me managing complexity while being able to check consistency as part of my unit tests.

BTW I was already toying with ARM JSON files generation a few years ago leveraging Jinja2 :)
But as it's only "syntactic macros", a lot of semantic issues are not detected as they should and are with something like Bicep...

@jfe7
Copy link

jfe7 commented Nov 23, 2021

This would be great if we could split out Bicep files like that!

Any news on this?

@TazzyMan
Copy link

Like I said in issue #7726 I would then also like to add parameters and expressions (to do some string manipulation if needed) to add re-use value (predefined template files for several resources with all the properties that are always the same in your organization)

@enbridgeint
Copy link

Good Ask....For me I want parameters in a file and remaining code in another file. is it possible?

I have n number of resources to create, so it will be good and traceable if we have different file param and different file for resources/modules

@SPSamL
Copy link

SPSamL commented Mar 14, 2023

When using Terraform, this template was the initial setup of other organizations', or tenants', spoke subscription. It deployed a core set of resources to integrate with the common services/hub subscription. They're split mostly by resource type plus Data Sources (Existing resources in Bicep), outputs, providers, and variables (Bicep Parameters). It was deployed by the same team every time. Modules are overkill for the resource types with multiple instances because they had different requirements for configurations such as 3 different Key Vaults: 1 for Customer Managed Keys, 1 for Certificates, and another for Secrets. They each had a specific set of access for the service account creating them and their secrets/keys/certs and different network restrictions. I simplified it down to a handful of variables/parameters that were required for each to basically just the name and location. The *_permissions were the same for each tenant.

It's also easier for the team, which I've left, to maintain or update than as a single file which would be around 2000 lines of code.

image

@Lddeiva
Copy link

Lddeiva commented Aug 4, 2023

@alex-frankel Is this still being considered? One of our customers is hitting the limit and wants to know if there are any solutions.

@alex-frankel
Copy link
Collaborator

@Lddeiva - it's not being actively considered. Having said that, I don't think if we implemented this it would address the limit you are talking about. I am assuming you are talking about the 4MB template size limit? We have a separate work item to try to get that limit raised.

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

No branches or pull requests