<@U04MT3AFGGY> just following up from <this thread...
# contributors
@prehistoric-article-73489 just following up from this thread: Have you seen the repos and projects description in this docs page? I’m thinking deployment scope, resource group name, location etc. can initially be treated as project-level inputs in the infracost config-file, similar to how users can provide TF vars or var-files or env vars for a TF project. Would something like this work?
Copy code
version: 0.1
    - path: my-whatif.json
      name: development
      arm_location: us-east-1
      arm_resource_group_name: myRG
      # or something like this so the same param names to the ARM CLI can be defined?
        location: us-east-1
        resource_group_name: myRG
or are location/depl-scope/resource-grou-name the same across all projects in a repo?
I'm not 100% certain about the usecase for more than one project, would have to talk to some others for that. Can't hurt to implement it for multi project anyway imo. This would mean adding extra properties to
if I understand it correctly?
yep, that’s how we do it for TF. This is interesting too, thinking out loud this is what the CLI experience could look like too
Copy code
For TF:
--terraform-var param1=value1 --terraform-var param2=value2
--terraform-var-file dev.tfvars

In infracost config file each project can have: terraform_vars and terraform_var_files

For ARM:
--arm-param param1=value1 --arm-param param2=value2
--arm-param-file storage.parameters.json

In infracost config file each project can have: arm_params and arm_param_files
Ah good idea, I'll talk to some colleagues about how this usecase would look. But this is at least a good direction to get it to work! Thanks for the quick response 🙂 We'll hopefully open a PR soon-ish to get some early feedback.
Heya, I got ARM/Bicep templates working for input. Would you mind looking over the azurerm provider code (https://github.com/XpiritBV/infracost-arm-support/tree/master/internal/providers/azurerm) and giving some feedback before we invest more time into robustness and resource support? We're looking for functional/big-picture feedback, there's still much cleaning up to do :)
Hey Jesse! Sure, we’ll try to get back to you by end of next week (we’re heads-down finishing a new onboarding flow that is close to shipping)
Hi @prehistoric-article-73489, I’ve taken a quick peek at that in progress fork and big picture it LGTM. Seems like the main components are there and the initial separation of components seems sensible. Obviously there’s quite a lot that we’d need to change before/if it gets merged in, but it looks like you’re on the right track. Let me know if you have any other questions.
Thank you @mysterious-teacher-68276, i'll give it another pass next week to add some more stuff.