infracost-atlantis
infracost-atlantis copied to clipboard
infracost
Warnings/deprecations fail Atlantis plans/applys
A user mentioned the following, we should test the integration with latest version of Infracost and latest version of Atlantis to see if we can reproduce this:
I'm not sure if it's Infracost and the way it runs the Terraform commands or the newer version of Atlantis we installed when we enabled Infracost, but our Atlantis Plans/Applys show as failed in the GitHub comments now if either of these are true. Warnings about targeted plan/apply Deprecation warnings in the plan/apply
Following up. I see this show command is throwing an exit status 1. So GitHub thinks the check has failed I suppose?
I put my repoBlock from the Atlantis Helm chart below.
running terraform show: running "/atlantis-data/bin/terraform1.2.5 show -json /atlantis-data/repos/foo/foo-terraform/816/foo-lab/spokes/foo-lab/foo-lab-foo-lab.tfplan" in "/atlantis-data/repos/foo/foo-terraform/816/foo-lab/spokes/foo-lab": exit status 1
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# module.aks.module.aad_pod_identity.helm_release.aad-pod-identity will be updated in-place
~ resource "helm_release" "aad-pod-identity" {
id = "aad-pod-identity"
name = "aad-pod-identity"
# (27 unchanged attributes hidden)
+ set {
+ name = "nmi.loggingFormat"
+ value = "json"
}
- set {
- name = "operationMode" -> null
- value = "managed" -> null
}
+ set {
+ name = "operationMode"
+ value = "managed"
}
}
Plan: 0 to add, 2 to change, 0 to destroy.
╷
│ Warning: Resource targeting is in effect
│
│ You are creating a plan with the -target option, which means that the
│ result of this plan may not represent all of the changes requested by the
│ current configuration.
│
│ The -target option is not for routine use, and is provided only for
│ exceptional situations such as recovering from errors or mistakes, or when
│ Terraform specifically suggests to use it as part of an error message.
╵
╷
│ Warning: Deprecated Resource
│
│ with azurerm_function_app.platform,
│ on functions.tf line 29, in resource "azurerm_function_app" "platform":
│ 29: resource "azurerm_function_app" "platform" {
│
│ The `azurerm_function_app` resource has been superseded by the
│ `azurerm_linux_function_app` and `azurerm_windows_function_app` resources.
│ Whilst this resource will continue to be available in the 2.x and 3.x
│ releases it is feature-frozen for compatibility purposes, will no longer
│ receive any updates and will be removed in a future major release of the
│ Azure Provider.
│
│ (and 2 more similar warnings elsewhere)
╵
╷
│ Warning: Argument is deprecated
│
│ with azurerm_subnet.aks,
│ on networking.tf line 34, in resource "azurerm_subnet" "aks":
│ 34: enforce_private_link_endpoint_network_policies = true
│
│ `enforce_private_link_endpoint_network_policies` will be removed in favour
│ of the property `private_endpoint_network_policies_enabled` in version 4.0
│ of the AzureRM Provider
│
│ (and 3 more similar warnings elsewhere)
╵
╷
│ Warning: Content-Type is not recognized as a text type, got "application/x-pem-file"
│
│ with module.aks.data.http.azure_mysql_ca,
│ on ../../modules/aks/k8s-datadog.tf line 36, in data "http" "azure_mysql_ca":
│ 36: data "http" "azure_mysql_ca" {
│
│ If the content is binary data, Terraform may not properly handle the
│ contents of the response.
╵
repoConfig: |
---
repos:
- id: /.*/
apply_requirements: ["approved", "undiverged"]
allowed_overrides: ["workflow"]
allow_custom_workflows: true
workflow: terraform-infracost
post_workflow_hooks:
- env:
name: INFRACOST_ENABLE_CLOUD
value: true
- run: |
if [ ! -d "/tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM" ]; then
exit 0
fi
infracost comment github --repo $BASE_REPO_OWNER/$BASE_REPO_NAME \
--pull-request $PULL_NUM \
--path /tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM/'*'-infracost.json \
--github-token $INFRACOST_GITHUB_TOKEN \
--behavior new
rm -rf /tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM
workflows:
terraform-infracost:
plan:
steps:
- env:
name: INFRACOST_OUTPUT
command: 'echo "/tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM/$WORKSPACE-${REPO_REL_DIR//\//-}-infracost.json"'
- env:
name: INFRACOST_ENABLE_CLOUD
value: true
- init
- plan
- show # this writes the plan JSON to $SHOWFILE
- run: |
if [ ! -d "/tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM" ]; then
mkdir -p /tmp/$BASE_REPO_OWNER-$BASE_REPO_NAME-$PULL_NUM
fi
infracost breakdown --path=$SHOWFILE \
--format=json \
--log-level=info \
--out-file=$INFRACOST_OUTPUT
@wobo-mattmencel what version of Atlantis are you using?
https://www.runatlantis.io/docs/custom-workflows.html#custom-run-command is the relevant doc:
SHOWFILE - Absolute path to the location where Atlantis expects the plan in json format
to either be generated (by show) or already exist (if running policy checks). Can be used
to override the built-in plan/apply commands, ex.
run: terraform show -json $PLANFILE > $SHOWFILE
It's odd that terraform show is failing for you, I'm guessing apply will also fail even if you comment-out the show and the infracost run steps? Per the above doc, you can remove show and instead add a run step that does terraform show -json $PLANFILE > $SHOWFILE || true to always force the show step to pass but then Infracost won't be able to run if there is no plan JSON file located at $SHOWFILE.
Hey @alikhajeh1 We're running the latest infracost-atlantis docker image.
It may be related to running targeted applies? e.g. atlantis plan -- -target=module.foo
We just had a case of this pop up a few minutes ago. I jumped into the Atlantis pod's terminal and ran the show command that produces the exit 1 code and see a bunch of plugin schema errors.... which don't appear in the GitHub PR comments.
/atlantis-data/bin/terraform1.3.0 show -json /atlantis-data/repos/ORG/terraform/868/spoke-lab-westus/spokes/spoke-lab-westus/spoke-lab-westus-spoke-lab-westus.tfplan
╷
│ Error: Failed to load plugin schemas
│
│ Error while loading schemas for plugin components: 13 problems:
│
│ - Failed to obtain provider schema: Could not load the schema for provider registry.terraform.io/cloudflare/cloudflare: failed to instantiate provider "registry.terraform.io/cloudflare/cloudflare" to obtain schema: unavailable provider
│ "registry.terraform.io/cloudflare/cloudflare".
│ - Failed to obtain provider schema: Could not load the schema for provider registry.terraform.io/cloudposse/utils: failed to instantiate provider "registry.terraform.io/cloudposse/utils" to obtain schema: unavailable provider
│ "registry.terraform.io/cloudposse/utils".
etc....
OK that might be a red herring. I think it might be this...
$ /atlantis-data/bin/terraform1.3.0 show -json spoke-lab-westus-spoke-lab-westus.tfplan
Failed to marshal plan to json: error marshaling prior state: unsupported attribute "only_protected_branches"
And if I run that command in the terminal without the -json it works fine.
@wobo-mattmencel this looks like it might be the same as https://github.com/hashicorp/terraform/issues/23297, so I wonder if the plan was somehow generated with different provider versions?
