plugin declaration without version

[grumpper]

Hi,

Currently in order for the aws plugin to be correctly installed it must be declared in .tflint.hcl with version and source parameters provided.
If you skip the version parameter it complains that you cannot only use the source one by itself.
If you skip the source parameter as well it cannot download and install the plugin at all.

Now if I have 200 repos containing TF code and for each I setup a pipeline for the repo to do tflint checks, each time you release a new version I have to go and edit the .tflint.hcl file in the repo that is used by the pipeline to reflect the new version of the aws plugin.
This results in 200 commits and PRs.

Can we instead utilize a keyword in the version like latest or $Latest or just make the version parameter optional and if not present the latest version of the plugin to be downloaded by default?

[wata727]

Thank you for your feedback.

I understand that requiring over 200 PRs is a pain, but isn't that a similar problem with required_version and required_providers.*.version? I'm interested in why these are not the problem and TFLint plugin version is.

Regarding the introduction of the latest keyword, I'm not positive due to stability issues. I believe it's better to have 200 PRs than to have 200 repositories' builds suddenly break one day. See also #1181

However, if you have any good ideas to eliminate these concerns, we can introduce a new version declaration mechanism. What do you thunk?

[wata727]

Maybe ideas like remote config will help.
https://github.com/terraform-linters/tflint-load-config-action

[grumpper]

Hi,

thank you for your feedback!

isn't that a similar problem with required_version

It isn't since you can have all kind of relaxed constraints like ~> or >=. I would be happy to have aws >= 0.20 for example but versioning here is strictly equal something so it's way more limiting than required_version.

remote config also won't work since one will eventually need to have custom stuff set in tflint.hcl per repo (i.e. for this particular repo ignore unused declarations but not for others). So one unified config won't be applicable for every use case and we are back at the problem.

What I am suggesting is basically the behavior for docker images - if you don't specify version pull the latest one, however your comparison with terraform's constraint mechanism is even better. If the same approach can be implemented in tflint it would be awesome but it still boils down to having version as optional parameter that when missing results in downloading the latest one.

The discussion in #1181 somehow steered into what is the most convenient way to handle tflint --init on a personal machine.
I do believe in the CI/CD era where tflint is primarily used as static code analysis tool in a pipeline part of git repository that the proposed solution to use (therefore enforcing usage) of a random third-party tool to handle versioning is counter-productive. Imagine Hashi telling you "well you can hardcode terraform's version if you want but once you do init on your machine it would be sufficient... for other purposes use dependabot"

Isn't it straight-forward to implement the following behavior based on what is described here: https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases

If version is defined behavior is the current one which I assume is to download from https://github-repo/releases/download/VERSION/plugin-release-platform-arch.zip
If version is not defined, download from https://github-repo/releases/latest/download/plugin-release-platform-arch.zip

Not sure about the stability issues but it looks like it's a simple URL handling.

Context: This whole discussion started since the tflint-bundle project was deprecated. It worked perfectly for me just using the latest image. Now to continue this I have to fork it.

[wata727]

It isn't since you can have all kind of relaxed constraints like ~> or >=. I would be happy to have aws >= 0.20 for example but versioning here is strictly equal something so it's way more limiting than required_version.

Hmm, but considering the locked version I feel it's similar. In fact, the company I work for has required_providers with constraints defined in about 50 workspaces, and uses Renovate to update all locked versions. Are you assuming a different workflow?

remote config also won't work since one will eventually need to have custom stuff set in tflint.hcl per repo (i.e. for this particular repo ignore unused declarations but not for others). So one unified config won't be applicable for every use case and we are back at the problem.

It makes sense. If remote config inheritance were possible, would this problem be solved? Imagine something like RuboCop's inherit_from.

Context: This whole discussion started since the tflint-bundle project was deprecated. It worked perfectly for me just using the latest image. Now to continue this I have to fork it.

Interesting as I didn't understand the use of tflint-bundle like this. Given that background, it's possible to revert the deprecation, but still, for this use case, I don't think tflint-bundle is the most appropriate. The latest version carries the risk of abruptly introducing breaking changes in the latest TFLint version, so pinning to the version is always recommended for a stable CI/CD pipeline.

[grumpper]

Of course mine is just a personal opinion and naturally to each their own but I think the most flexible and therefore liberating approach in terms of version is for it to be optional. This way organizations that use Rennovate or Dependabot or whatever can handle constraint that way whereas others that do not use such third-party tools can also implement convenient workflows without time consuming hardcoding. So to TL;DR: versioning should not enforce implementation approach.

In terms of my organization's workflow.
What we have been doing for years without issues is having .tflint.hcl per repo and then we have this step to analyze the code:

- step:
    name: TFLint
    image: ghcr.io/terraform-linters/tflint-bundle:latest
    script:
      - tflint --init
      - tflint --chdir terraform/ -c ../.tflint.hcl

So far I have recreated it: https://github.com/meltingcore/tflint-bundle.
I want things to happen automatically (as outlined in the To Do section but for now I just want to make sure I have up-to-date images).