feat: Support set custom TF/OpenTofu binary. | If you use a custom Docker image build, please note that TERRAFORM_VERSION now must be provided

[den-is]

Put an x into the box if that apply:

• This PR introduces breaking change.
• This PR fixes a bug.
• This PR adds new functionality.
• This PR enhances existing functionality.

Description of your changes

Allow setting custom TF binary.

• provide per hook setting --hook-config=--tf-path=<path_to_binary_or_binary_name>
• export ENV variable PCT_TFPATH=<path_to_binary_or_binary_name>
• export ENV variable TERRAGRUNT_TFPATH=<path_to_binary_or_binary_name>
• if none of above are set defaults to terraform binary found in the user's $PATH
• if none of above are set/available defaults to tofu binary found in the user's $PATH
• in the end, if none of above is set/available - exit 1 with error message

Side feature. Fixes bad README.md

I'm open to any suggestion and contributions.

Fixes #570

How can we test changes

Create dummy repository with a dummy terraform module test

mkdir test
cd test
git init

Add files to test/:
.pre-commit-config.yaml

repos:
- repo: local
  hooks:
  - id: terraform_fmt
    name: terraform_fmt
    entry: /path/to/pre-commit-terraform/hooks/terraform_fmt.sh
    language: script
    files: \.tf$
    # Uncomment these lines. Or set global ENV variables PCT_TFPATH or TERRAGRUNT_TFPATH
    #args:
    #- --hook-config=--tf-path=tofu

main.tf

# dummy terraform file with ugly formatting
resource "null_resource" "print_time" {
triggers = {
current_time = timestamp()
}

provisioner "local-exec" {
command = "echo Current time is ${triggers.current_time}"
}
}

Run in the test module directory:

pre-commit install
pre-commit run --verbose --files main.tf

[den-is]

Pushed final README fixes. Missed the broken README part the last time when I was reverting back to */

[MaxymVlasov]

I don't get it

According to https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-tfpath it will be automatically specified for terragrunt => for terragrunt hooks too.

Why do we need to set Terragrunt path for vanilla TF hooks?

[den-is]

Imagine you are working in some environment that already uses TERRAGRUNT_TFPATH env variable (global env, using direnv, or any other method)
So if a variable already exists and serves exactly the same purposes, why not to check it and reuse it, why to have other args/vars/etc?

[yermulnik]

Not sure I'm following the gist of the question, though probably (I'm purely guesstimating) this way it would be easier for people using both TF and TG hooks to specify custom binary only once using TG's method but covering also TF? 🤔 And from this point of view it makes sense to me.

@den-is What's your idea?

[den-is]

Not sure I'm following the gist of the question, though probably (I'm purely guesstimating) this way it would be easier for people using both TF and TG hooks to specify custom binary only once using TG's method but covering also TF? 🤔 And from this point of view it makes sense to me.

@yermulnik Erm... this was already replied to by me yesterday.

[MaxymVlasov]

Folks that use terragrunt should use terragrunt hooks, not terraform hooks - terraform will just not work in most cases. It's hard to imagine that someone uses both terragrunt and vanilla terraform, but if so - why do we think that folks would be happy with interference between "prj1 with TG and OpenTofu" and "prj2 with vanilla TF"?

And another question: do we need to specify $tf_path for terragrunt hooks?

Like terragrunt validate --terragrunt-tfpath "$tf_path" "${args[@]}"

pre-commit-terraform/hooks/terragrunt_validate.sh

Line 46 in 1ac4f2d

terragrunt validate "${args[@]}"

[yermulnik]

Erm... this was already replied to by me yesterday.

@den-is My bad. I missed that comment (found it now). Thanks.

[yermulnik]

It's hard to imagine that someone uses both terragrunt and vanilla terraform

I don't in particular, but a fellow squad in my project — does. And I'd imagine there are people in the wild who do the same and hence they may like using TERRAGRUNT_TFPATH to cover both use cases if they use pre-commit-terraform.

And another question: do we need to specify $tf_path for terragrunt hooks?

That's a good question. We probably should. But only when it is provided via TG hook config. In the rest of use cases TG should rely upon its own logic, including TERRAGRUNT_TFPATH and others described at https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-tfpath

[MaxymVlasov]

Had a conversation with @den-is
TL;DR: we assume that it will no break anything in 99% of cases. And if such a thing happened - I'll mention Den is such an issue :D

[yermulnik]

Works for me 👍🏻

I'll mention Den is such an issue :D

I feel like is should be in, but with is the sentence sounds fabulous 🤣

[yermulnik]

Not sure I'm following the gist of the question, though probably (I'm purely guesstimating) this way it would be easier for people using both TF and TG hooks to specify custom binary only once using TG's method but covering also TF? 🤔 And from this point of view it makes sense to me.

@den-is What's your idea?

[yermulnik]

LGTM apart from #670 (comment) that I didn't get why TF switched from latest to exact version.

[den-is]

This was fixed by VSCode automatically.
Will check for workaround

[den-is]

Imagine you are working in some environment that already uses TERRAGRUNT_TFPATH env variable (global env, using direnv, or any other method)
So if a variable already exists and serves exactly the same purposes, why not to check it and reuse it, why to have other args/vars/etc?

[den-is]

Not sure I'm following the gist of the question, though probably (I'm purely guesstimating) this way it would be easier for people using both TF and TG hooks to specify custom binary only once using TG's method but covering also TF? 🤔 And from this point of view it makes sense to me.

@yermulnik Erm... this was already replied to by me yesterday.

[yermulnik]

This was fixed by VSCode automatically.
Will check for workaround

Add the below to config of VSCode of yours:

    "[markdown]": {
        "files.trimTrailingWhitespace": false
    }

Other common useful settings VSCode usually is missing from what I've found from experience of others using it:

    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true,
    "files.trimFinalNewlines": true,

[den-is]

This was fixed by VSCode automatically.
Will check for workaround

Add the below to config of VSCode of yours:

    "[markdown]": {
        "files.trimTrailingWhitespace": false
    }

Other common useful settings VSCode usually is missing from what I've found from experience of others using it:

    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true,
    "files.trimFinalNewlines": true,

lol dude... i always have this setting in all my editors... for years... you basically copy pasted my snippets which I add to different projects were noobs can't solve their whitespace issues.

Only thing I was not able to find correct settings for VSCode to fix * replacement with -. (Well I did not spend hours to find it in VSCode... just used vim to revert to your standard)

[MaxymVlasov]

Space trimming and so on should be done by .editorconfig in the first place, as is supported by everything, including vim.

TOC is not supported by built-in MD engine, for this I use https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one

With

    "markdownlint.config": {
        "MD029": false,
        "MD012": {
            "maximum": 5
        }
    },
    "markdown.extension.toc.unorderedList.marker": "*",
    "markdown.extension.toc.levels": "2..6",

I'll check vanilla VS Code settings and then will send PR which will add needed configs and/or rewrite MD file

[den-is]

In case if person uses VSCode, most of .editorconfig settings are supported natively. Otherwise you have to install another extension.

But yea, addined .editorconfig to you project makes it clear what formatting you require and ask to match. (from those who can't configure their IDEs with universal/common/common-sense/not-personal settings)

[yermulnik]

Only thing I was not able to find correct settings for VSCode to fix * replacement with -. (Well I did not spend hours to find it in VSCode...

It's probably not the VSCode per se, but an extension. Like some of these: https://github.com/yzhang-gh/vscode-markdown or https://github.com/prettier/prettier-vscode

BTW FWIW: yzhang-gh/vscode-markdown#145

just used vim to revert to your standard)

It's not ours. It's Markdown language specification. Unless you prove otherwise.

PS: I looked at markdownlint rules and they seem to prefer * over - for unordered lists in documentation — https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md 🤔

[antonbabenko]

This PR is included in version 1.90.0 🎉