Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for terraform test #549

Open
tasansga opened this issue Aug 1, 2023 · 6 comments · May be fixed by #581
Open

Support for terraform test #549

tasansga opened this issue Aug 1, 2023 · 6 comments · May be fixed by #581
Labels
estimate/1day Need 1 work day to be done feature New feature or request good first issue Good for newcomers

Comments

@tasansga
Copy link

tasansga commented Aug 1, 2023

What problem are you facing?

I want to run terraform test in a pre-commit hook if either the module or one of the module's tests changed.

terraform test has been around since at least 2021 and became quite usable with the precondition and postcondition blocks introduced in terraform 1.2.0, but is nevertheless still a "experimental" feature of the terraform CLI.

How could pre-commit-terraform help solve your problem?

In principle terraform test is "just the same" as the terraform validate hook, except that it should be only triggered if either dir_path has a parent directory that is called tests (i.e. there is a changed test in the commit) or dir_path has a child directory that is called tests (i.e. there is a change in the module). Either way, terraform test would be run from the terraform module root directory and it should fail the commit if the tests do not pass.

@tasansga tasansga added the feature New feature or request label Aug 1, 2023
@MaxymVlasov MaxymVlasov added good first issue Good for newcomers estimate/1day Need 1 work day to be done labels Aug 14, 2023
@MaxymVlasov
Copy link
Collaborator

I haven't used terraform test yet but would be nice to have that hook.

Also, terraform test will be GA in 1.6.0, with huge changes

This comes with a significant change in how Terraform tests are written and executed.

Terraform tests are now written within .tftest.hcl files, controlled by a series of run blocks. Each run block will execute a Terraform plan or apply command against the Terraform configuration under test and can execute conditions against the resultant plan and state.

https://github.com/hashicorp/terraform/releases/tag/v1.6.0-alpha20230802

So I propose to wait with hook implementation until TF 1.6.0 release

@hoangelos
Copy link

I'd be happy to contribute to this.

@MaxymVlasov
Copy link
Collaborator

@hoangelos hoangelos linked a pull request Oct 29, 2023 that will close this issue
4 tasks
@hoangelos
Copy link

I submitted a PR for this. There's only one problem. It would run also when .tftest.hcl files are updated too and not just .tf files. However, there's a problem with the logic of files that "assumes" that the directory the files that match is the directory you want to run the command from. This is not true with test. Also, this requires terraform 1.6.x obviously.

@yermulnik
Copy link
Collaborator

I haven't yet made it to employ TF tests for my use cases, hence I'm speaking more of speculatively, though I see the logic like this: 1) when any of TF Config files (tf/tfvars) are changed, run TF test if there are any TF Test files present in the directory with each changed TF Config file + 2) when any of TF Test files are changed, run TF test in the directory with each changed TF Test file (optionally with a conditional of "if there are any TF Config files present in the directory with each changed TF Test file").
Let's move discussion to #581

@brettcurtis
Copy link

brettcurtis commented Apr 7, 2024

This is some feedback since I'm migrating from Kitchen-Terraform to Terraform test. I could see running unit tests as part of pre-commit helpful, but running what they are branding as integration tests would be far too long of a feedback loop in its current implementation. Each run tears down the infra, and subsequently, the next run needs to rebuild it. This makes integration tests unusable for almost everything we do or anything that takes longer than a few minutes.

Tests can run a command of plan == unit test or apply == integration based on the language in their blog post. This is hardcoded in the test and can't be passed in the CLI yet (I'll check for an issue and open one if not), which presents an implementation detail as far as this issue goes. I suppose we could use separate test files but that would probably be a lot of copy/paste.

Anyways, just some thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimate/1day Need 1 work day to be done feature New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants