Add Binary Releases

[osterman]

what

• Add semver releases
• Attach precompiled binaries to the releases

why

• Not everyone has a go setup
• GitHub actions make it trivial to build and distribute binary releases (happy to provide example)

[pselle]

@osterman We do not intend to add releases to this project. However, it would be helpful if you shared a bit more about the use cases why/where you're using terraform-config-inspect and why a binary release would be helpful to that workflow.

[osterman]

Thanks @pselle for the update.

Here's our use-case.

Cloud Posse is a massive user of Terraform, as well as dozens of other tools. We distribute our toolchain as alpine, debian, and redhat packages so we have a consistent way for each distribution to install the tools. These are tools we use in our docker images, local development and test infrastructure. Having a package management system makes that very easy for our community and customers.

We now rely on terraform-config-inspect for our tests to pass. We use it to ensure all modules are pinned to a version and not a branch.

problem

Every package management system out there relies on semver. In order to release a package for terraform-config-inspect we need to have a semantic version associated with it.

Additionally, without releases, it's hard to pin to a version. Granted we could pin to a SHA, the sha is not a valid semver.

Depending on go get as the installer requires a go build system, which limits adoption. At the same time, the terraform-config-inspect tool is not limited to developers of terraform-the-language; it's useful for developers using the language, who don't have go setup.

solution

Our solution to releases is very easy and could be adopted by this project.

The gist of it is always cut a release on merge to master. I could also share how we do it, but sounds like GitHub actions like the one we use are not in scope. =)

---

It'd be helpful to understand what the opposition is to cutting releases and distributing binaries? =)

[tbugfinder]

Code for PR is already there.

https://github.com/Bonial-International-GmbH/terraform-config-inspect/commit/c38bd00ced3c613b87a42803ab9597d15c5718c2

[xp-1000]

hello @osterman

we also use terraform a lot at Claranet and I use terraform-config-inspect in some of our CIs also to check some things but more to "parse" hcl module config (i.e. to get default value of variables).

I also would prefer to rely on release but I use a docker image (https://hub.docker.com/repository/docker/claranet/terraform-ci) to workaround this (CI uses this image ensuring the "version" is the always the same even if it does not point to any tag/release while the docker image is not updated itself).

To check if a module is pinned I use https://github.com/terraform-linters/tflint/ with the rule terraform_module_pinned_source may be it can help you.

[osterman]

Thanks @xp-1000 that's a good tip!

[robinbowes]

It'd be helpful to understand what the opposition is to cutting releases and distributing binaries?

I too would like to know what the opposition is to cutting releases?

R.

[haidaraM]

Same need for a release. We use terraform-config-inspect to generate a web page with all the Terraform projects at our organization for tracking purpose. This web page contains for each project the list of modules and providers used.

[nikolay]

Any update?

[stevehipwell]

👀