This message was deleted.

👋 Hi Stephen, sorry to hear about those troubles! Our team’ll look into this more tmrw probably but a quick note on #2, you need to provide the API key from step 1 into gitlab, as that is the API key you generated for your installation. Is that what you tried already? The API key you got from

infracost auth login

is only used to download the pricing DB dump from our service (so your self-hosted instance stays uptodate with latest price changes automatically).

Yes I added that key and still no luck. I get the following error -> Error: No valid Terraform files found at the given path, try a different directory Try setting --path to a Terraform plan JSON file. See https://infracost.io/troubleshoot for how to generate this. time="2022-07-27T220558Z" level=warning error="Invalid API key" msg="error reporting CLI error" But the Terraform plan in the previous stage passes and works fine. One caveat though I had to change this line -> plan_json_path=$(echo $run_plan_resp | sed 's/.*\"json-output\":\"\([^\"]*\)\".*/\1/') from this CI template. Within the CI Template to be json-output-redacted to get the CI stage to work and generate the plan.json.

ah the “Invalid API key” error is a red herring, ignore that (I’ll create an issue so we fix that error message). I think the issue is that

--path

flag isn’t pointing to terraform directory or plan JSON file. Can you

cat $plan_json_path

to see if it’s the right path or if it’s a valid plan JSON file?

Yes I did and it's valid JSON the command and how it's pointed at the plan.json is from the GitLab CI templated. But I will set up the CLI locally and get back with you to reconfirm.

Let us know how it goes, we often find it quicker to jump on a quick Zoom call to debug via screenshare so our team can do that too (I’m flying tmrw but happy to do this on Monday if we don’t fix the issue tmrw)

Oh wow! That's awfully kind of you. Will do for sure! I am also traveling. So will get back to this thread on Monday as well

Hi Stephen, just a note on your first issue. It’s a known issue and at the moment the docs just say to delete the init job before upgrading (https://github.com/infracost/helm-charts/tree/master/charts/cloud-pricing-api#upgrade-to-latest-version). My helm skills are definitely lacking, but I’m guessing we could just use the

post-install

helm hook to run the job only on install and clean it up afterwards. Let me know what you think and if you have any other ideas?

Yes a post-install would be a good way to go

@brief-raincoat-4753 I’m around for another 2 hours if you want to jump on a screenshare to debug more, DM me here if you like

In 30-45 minutes i can hop on a call

@little-author-61621 I paired with @brief-raincoat-4753 to debug but we still couldn’t fix the issue. Can you review this to see if anything jumps out at you? They’re using Terraform CLI 1.1.7, and Terraform Cloud’s remote execution mode and plan JSON method (not parsing HCL). They’re downloading the plan.json using curl as described here, but as they mentioned above,

plan_json_path=$(echo $run_plan_resp | sed 's/.*\"json-output\":\"\([^\"]*\)\".*/\1/')

had to be changed to use

json-output-redacted

to get the CI stage to work and generate the plan.json. I can’t find anything about

json-output-redacted

in the Terraform Cloud API docs. When plan.json is downloaded to the directory that has the plan terraform project,

infracost breakdown --path=plan.json --log-level=debug

shows (notice the odd

provider=terraform_dir

):

time="2022-08-01T19:23:41Z" level=debug enable_cloud_os=false func="<http://github.com/infracost/infracost/internal/hcl.(*projectLocator).walkPaths|github.com/infracost/infracost/internal/hcl.(*projectLocator).walkPaths>" file="/app/internal/hcl/parser.go:607" enable_cloud_comment=false project_name= provider=terraform_dir project_path=./plan.json routine=7 currency=USD sync_usage=false msg="walking path ./plan.json to discover terraform files"

When plan.json is downloaded to an empty directory,

infracost breakdown --path=plan.json --log-level=debug

shows:

Error: No valid Terraform files found at the given path, try a different directory
Try setting --path to a Terraform plan JSON file. See <https://infracost.io/troubleshoot> for how to generate this

So it seems like the CLI isn’t able to detect the file as a valid Terraform plan JSON. When we

cat plan.json | jq

it shows ok, meaning it’s a valid JSON file. Running

cat plan.json | jq '. |= keys'

shows:

[
  "output_changes",
  "provider_schemas",
  "resource_changes",
  "resource_drift"
]

I'm out at the moment, but will look more when I'm back. First thought is that the format of the JSON doesn't look like what we support. We are looking for

planned_values

. I'm guessing the "redacted" JSON format is different. So my first thought is to look at what the resp we get from Terraform Cloud is in the

run_plan_resp

When trying to leverage the

json-output

format it fails to pull it from the API. Why idk 🤷 but when i change that line to be

json-output-redacted

and pull the plan from this endpoint it works. However, after talking with @white-airport-8778 and leveraging this template instead. I was able to get the results i wanted. However, I couldn't when using the other example template i posted at the start of this thread.

Ok great! I was wondering if you knew of any setting you might have enabled on Terraform Cloud that meant the

json-output-redacted

was returned instead of

json-output

. But, the other template you got working is great since it doesn’t rely on pulling any plan JSON form Terraform Cloud simple smile

@brief-raincoat-4753 that’s great! Out of interest, did you add

INFRACOST_TERRAFORM_CLOUD_TOKEN

so your vars are fetched from there? Are you now seeing gitlab merge-request comments ok?

yes

@brief-raincoat-4753 I was reviewing my notes from our debugging session and I think you mentioned

INFRACOST_ENABLE_CLOUD: false

was causing errors in the gitlab CI yaml? do you remember what the error was?

Was just saying it was invalid yaml. But the precise error off the top of my head no