hey folks, hopefully simple question. Does the Infracost graphQL API

attributeFilters

property map back to Terraform resource properties? or is there some magic/translation in the CLI that looks up the Terraform properties from the API?

Hi lee, it’s the latter

would you be able to point me to where the code is that does that so I can try grok it?

Sure thing. Any particular reason, do you have a bug or problem with the cli? Something I can help with?

I’m trying to build a PoC integration with Pulumi’s providers, which bridge Terraform providers. It’s not possible to use a plan based method because of the dynamic nature of the Pulumi graph, so I’m trying to integrate with the policy engine Pulumi provides If the properties on the

attributeFilter

are similar to the Terraform properties (and therefore also the Pulumi properties) it would be straightforward to just send all of the key value pairs to the API, but if I have to mung them a bit that’s possible too@

hey @enough-scooter-95197 we already have an inflight pull request for Pulumi here: https://github.com/infracost/infracost/pull/1752. Which, is authored by one of the Pulumi team. I’d recommend following that for updates regarding Pulumi support. If you have a different strategy that you’d like to propose, could you comment/outline your strategy on that PR. This helps us keep track of the implementation in one place, and means we have greater public visibility. You’ll also be able to get answers to your original question by looking through the implementation on that PR. I hope this clarifies things.

Hey Lee - I've also been working with your partnership team on this topic 🙂

I work alongside Richard, this is primarily a proof of concept to try and detail a better way before making the idea public.

ok great, it might be best to sync up with Richard and make sure we don’t get duplicates. Then maybe we can add you to the dedicated Infracost <> Pulumi chat. However I just wanted to highlight something based on your previous response:

If the properties on the

attributeFilter

are similar to the Terraform properties (and therefore also the Pulumi properties) it would be straightforward to just send all of the key value pairs to the API, but if I have to mung them a bit that’s possible too

The properties sent to the pricing API are in large part not at all similar to the terraform properties. So this approach might not work at all. The translation layer from HCL to pricing lookup filters is normally incredibly involved and is not a simple 1-1 mapping. A good doc to understand how our resource mapping works is to read the “adding new resource guide” https://github.com/infracost/infracost/blob/master/contributing/add_new_resource_guide.md

that helps, thank you