Skip to content

Store and return last failure from validate vs exit on first failure#45

Merged
brikis98 merged 1 commit intogruntwork-io:masterfrom
davidalger:master
Dec 9, 2020
Merged

Store and return last failure from validate vs exit on first failure#45
brikis98 merged 1 commit intogruntwork-io:masterfrom
davidalger:master

Conversation

@davidalger
Copy link
Contributor

This PR accomplishes two things:

  • Cleans up output on terraform-validate adding informative marker indicating directory in which a failure occurred, which is crucial when running this in CI against a repository with a dozen or more modules.
  • Updates terraform-validate to correctly check each argument passed in by pre-commit rather than exiting on the first failure encountered.

Copy link
Member

@brikis98 brikis98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! How did you test this?

@davidalger
Copy link
Contributor Author

Here's what I did to test this:

a) Added the following to .pre-commit-config.yaml and then run pre-commit install in a local checkout of a terraform module:

repos:
  - repo: https://github.com/davidalger/pre-commit
    rev: "a787da3a8"
    hooks:
      - id: terraform-fmt
      - id: terraform-validate

Can also be done via HEAD referencing local checkout:

repos:
  - repo: ~/Work/pre-commit
    rev: "HEAD"
    hooks:
      - id: terraform-fmt
      - id: terraform-validate

b) Run pre-commit on all files with intentionally bad code:

$ pre-commit run --all-files
Terraform fmt............................................................Passed
Terraform validate.......................................................Failed
- hook id: terraform-validate
- exit code: 1

--> Running 'terraform validate' in directory '.'

Initializing provider plugins...
- Using previously-installed hashicorp/aws v3.20.0
- Using previously-installed hashicorp/template v2.2.0

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* hashicorp/aws: version = "~> 3.20.0"
* hashicorp/template: version = "~> 2.2.0"

Terraform has been successfully initialized!
Success! The configuration is valid.

--> Running 'terraform validate' in directory 'examples/cloud-init-users'
Initializing modules...
Downloading terraform-aws-modules/vpc/aws 2.33.0 for vpc...
- vpc in .terraform/modules/vpc

Error: Unsupported Terraform Core version

  on .terraform/modules/vpc/versions.tf line 2, in terraform:
   2:   required_version = "~> 0.12.6"

Module module.vpc (from terraform-aws-modules/vpc/aws) does not support
Terraform version 0.13.5. To proceed, either choose another supported
Terraform version or update this version constraint. Version constraints are
normally set for good reason, so updating the constraint may lead to other
errors or unexpected behavior.


Error: Unsupported Terraform Core version

  on .terraform/modules/vpc/versions.tf line 2, in terraform:
   2:   required_version = "~> 0.12.6"

Module module.vpc (from terraform-aws-modules/vpc/aws) does not support
Terraform version 0.13.5. To proceed, either choose another supported
Terraform version or update this version constraint. Version constraints are
normally set for good reason, so updating the constraint may lead to other
errors or unexpected behavior.

--> Running 'terraform validate' in directory 'examples/simple-app-server'
Initializing modules...

Initializing provider plugins...
- Using previously-installed hashicorp/random v3.0.0
- Using previously-installed hashicorp/aws v3.20.0
- Using previously-installed hashicorp/template v2.2.0

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* hashicorp/random: version = "~> 3.0.0"
* hashicorp/template: version = "~> 2.2.0"

Terraform has been successfully initialized!
Success! The configuration is valid.

Failed as expected with errors found in one of the validations.

c) Attempt to commit the bad code:

$ git commit -am "Test bad commit"
Terraform fmt............................................................Passed
Terraform validate.......................................................Failed
- hook id: terraform-validate
- exit code: 1

--> Running 'terraform validate' in directory 'examples/cloud-init-users'
Initializing modules...

Error: Unsupported Terraform Core version

  on .terraform/modules/vpc/versions.tf line 2, in terraform:
   2:   required_version = "~> 0.12.6"

Module module.vpc (from terraform-aws-modules/vpc/aws) does not support
Terraform version 0.13.5. To proceed, either choose another supported
Terraform version or update this version constraint. Version constraints are
normally set for good reason, so updating the constraint may lead to other
errors or unexpected behavior.


Error: Unsupported Terraform Core version

  on .terraform/modules/vpc/versions.tf line 2, in terraform:
   2:   required_version = "~> 0.12.6"

Module module.vpc (from terraform-aws-modules/vpc/aws) does not support
Terraform version 0.13.5. To proceed, either choose another supported
Terraform version or update this version constraint. Version constraints are
normally set for good reason, so updating the constraint may lead to other
errors or unexpected behavior.


Failed as expected.

d) Commit some passing changes to verify it passes:

$ git commit -am "Test good commit"
Terraform fmt............................................................Passed
Terraform validate.......................................................Passed
[master 56b151f] Test good commit
 1 file changed, 1 insertion(+)

e) Run pre-commit on all files again expecting no failures:

$ pre-commit run --all-files
Terraform fmt............................................................Passed
Terraform validate.......................................................Passed

@davidalger davidalger requested a review from brikis98 December 8, 2020 15:56
Copy link
Member

@brikis98 brikis98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic, thank you! I'll kick off the tests now.

@brikis98
Copy link
Member

brikis98 commented Dec 9, 2020

Tests passed! Merging now.

@brikis98 brikis98 merged commit 39887f3 into gruntwork-io:master Dec 9, 2020
brikis98 added a commit that referenced this pull request Dec 9, 2020
This PR updates the `terraform-fmt` hook as follows:

1. Extract all the directories with Terraform code first and run `terraform fmt` once per directory. 
1. Print out the directory where we're running `terraform fmt` to make debugging errors much easier.
1. Instead of exiting on the first error, save the exit codes, and print out all `fmt` errors before exiting.

These changes are very similar to #45.
@brikis98
Copy link
Member

brikis98 commented Dec 9, 2020

Ah, I just realized we should apply similar changes to the terraform-fmt hook too: #46

brikis98 added a commit that referenced this pull request Dec 10, 2020
This PR updates the `terraform-fmt` hook as follows:

1. Run with `-diff -check` so the differences are printed, rather than made on disk.
1. Instead of exiting on the first error, save the exit codes, and print out all `fmt` errors before exiting.

These changes are very similar to #45.
@brikis98
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants