Use version from packerfile

[F21]

It would be nice if the action can parse the required_version from the packerfile and use that to select the version.

This prevents duplication where we have the version set in both the packerfile and setup-packer's version input.

[ksatirli]

Thanks for suggesting this @F21!

We thought about this in the lead up, but haven't built anything yet, for a handful of reasons:

1.) Unlike Docker and other tools, Packer does not have a "default" file (Packerfile), so we'd need to parse all .pkr.hcl and .pkr.json files for the required_version attribute.

2.) We thought about dealing with this, by having the user specify a single file that should be scanned for required_version, but didn't like that approach either.

3.) If required_version is not a single version, but rather a range (> 1.5.0, < 2.0.0), what value should the Action use?

A few options that come to mind are:

• the lower-range (1.5.0)
• the latest patch release of the lower range (1.5.6)
• the higher range (latest 1.x release in this case)

Ranges makes this complex (not impossible to solve from a code perspective, but it introduces magic and I don't like that) and less predictable (because of said magic).

All this to say that, yes we understand the desire, but no, we don't currently have a good solution.

We'll keep thinking more about this! Please feel free to share your thoughts on this, so we can take it into account, too!

---

CC for @hashicorp/github-actions-maintainers and @JenGoldstrich specifically: I think this takes us back to the chat we had a few months ago of parsing the .hcl files with any of the available NPM libraries and then bubbling up the value and use it to inform setup-packer's version selection.

[F21]

I think the dflook/terraform-version action has solved all 3 points, so perhaps inspiration can be drawn from it.

[ksatirli]

@F21 the way I read https://github.com/dflook/terraform-github-actions/blob/main/image/entrypoints/version.sh#L11 is that terraform version -json gets executed inside a Docker image.

A few thoughts about this:

1.) To be able to run terraform version -json, we need access to the terraform binary.

In setup-packer, the binary gets loaded after the version is made available to the Action workflow (that is: the actor tells setup-packer they want packer version 1.11.0 for example, and the Action then downloads 1.11.0)

2.) Looking at some of my Terraform code, and running terraform version -json would produce an output like this:

{
  "terraform_version": "1.8.5",
  "platform": "darwin_amd64",
  "provider_selections": {
    "registry.terraform.io/hashicorp/aws": "5.38.0",
    "registry.terraform.io/hashicorp/hcp": "0.83.0",
    "registry.terraform.io/hashicorp/tfe": "0.52.0"
  },
  "terraform_outdated": false
}

This would be very straightforward to parse, but note that 1.8.5 here refers to the system-installed version of Terraform, not the version requested by the author of the Terraform files:

  required_version = ">= 1.7.0, < 1.8.0"

Which means we can't use the JSON output to inform what version of Terraform the Action should install (and this flow would still be blocked by the problem described in point 1)

  required_version = "1.11.0"

Ultimately, required_version was designed for the respective CLIs (terraform, packer, etc.) to determine their execution, not as something external tools should use to determine which version of a CLI to install.

We've got more thinking to do!

[F21]

For 1, perhaps the action can include a set version of terraform that is used to run the packer version command?

The terraform-version actions says its able to parse ranges in the required version. See: https://github.com/dflook/terraform-github-actions/blob/9c15d4619bef940788f55d85b3bc9df9dddda486/image/src/terraform_version/required_version.py#L20 Perhaps something similiar can be done here.

[ksatirli]

Hey @F21,

Similarly to terraform version, running packer version will only output the version of Packer installed on your system, not the version of Packer required by your Packer template files (*.pkr.hcl), so that wouldn't get us closer to your initial ask.

We'll keep iterating on how to deal with this, but including a binary by default and then replace it with a more version-appropriate binary isn't likely a path we'll go.