Open mfeyx opened 2 years ago
Duplicate #5742
hi @wsmelton,
I found that issue you mention above (#5742), but I thought it is not the same request as mine, even though it is similar. My suggestion is to not throw an error, like InvalidTemplate
, if a parameter is unused. There is no conditional logic behind my request. I hope I could make myself clear :)
Kind regards
Oh, the param file itself. I would believe that has to be addressed upstream since validating the param to the template is done at the deployment PUT endpoint.
Oh, the param file itself. I would believe that has to be addressed upstream since validating the param to the template is done at the deployment PUT endpoint.
Thanks for your quick response @wsmelton! When you say "upstream" you mean I have to file this request somewhere else?
Kind regards
Opened the issue elsewhere, so I will close it here.
Would it be possible to re-open this?
#5742 is not really a dupe of this at all.
Also this feature request should be handled on https://github.com/Azure/bicep/issues/7301 and tickets describing .bicepparams usage.
@jikuja agreed this is not a dupe and agreed we could (not necessarily should) feasibly address this with .bicepparams
support. I will re-open.
Curious to understand what the potential negative implications would be for starting to allow this. We could emit a warning in the language service and as part of emitting ARM parameters and ARM template. When would a warning not be sufficient? cc @bmoore-mstf who may know more about this.
One option might be adding option for tooling to
What would be correct level to implement this check?
API:
How does PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Resources/deployments/{deploymentName}?api-version=2021-04-01
and others handle deployments if properties.parameters
or properties.parametersLink
has unused parameters.
BCP259(1) is now making more client-side assumptions about failing when unused paramters are being passed.
(1) bicep build-params
=> $"The parameter \"{identifier}\" is assigned in the params file without being declared in the Bicep file."
+1 for this, would also help with Yaml templates for multiple deployments using same template
+1 for this issue. Our use case is that we want to split one large Bicep file that is describing all resources of a spoke into multiple smaller bicep files. This spoke is deployed multiple times (e.g. one for Dev environment, one for Test and so on), so having a single parameter file per environment would be ideal.
@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like
+1
@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like
Please look at the OP issue. Imagine a second bicep file that'll use both "rg_tags", "tags" and "name" parameters. That's exactly the case that you're looking for and what I'm facing right now.
In the meantime, I wrote a little helper script that can be found here: https://github.com/Azure/azure-cli/issues/21149#issuecomment-1256639995
@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like.
@alex-frankel Apologies for delay, i'll explain as best i can. We use YAML templates with CLI task and it uses parameters so we can use different bicep files with the same template as below.
Problem being we can only do this for bicep files that expect the same parameter inputs from Yaml, otherwise we have to create another template. Say for example 1 bicep file is expecting DNSSubscriptionID, but the second isn't. We then get error saying unexpected parameter.
if we could have the ability for bicep to ignore any parameters passed that are not declared, it would mean we could use the same YAML template file with all the Param overrides for all bicep main files. This would be unbelievable good.
+1
@alex-frankel Is this something that is being worked on by chance?
We have scenario where the vast majority of our bicep modules are using a central bicep module file for some key parameters etc, and having the ability to assign parameters up the chain using the .bicepparam file would be extremely useful to us.
Or perhaps there is a way to suppress error BCP259?
kind regards
+1
+1 This should be allowed. We use 1 BICEP params file for multiple deployments but due to this 'warning', we are unable to complete this the way we'd like. Its been 2 years (going on 3), i wonder if anyone cares about this issue.
@alex-frankel any update?
Is your feature request related to a problem? Please describe
I want to deploy resources based on a
params.json
file. If unused parameters are present the deployment currently fails:main.bicep
params.json
Describe the solution you'd like
Basically, I want to deploy resources without having to delete parameters in the parameters file. I want to be able to define parameters even though they might not be used in a deployment. When I deploy a resource group, for instance, I will use my
rg_tags
values from the parameters, but not the normaltags
that might be used in other deployments.Edit: Sorry, I forget the command I use.
Hope this is the right place for the suggestion.
Kind regards :)